Hi, On Fri, 13 Jul 2007, Mike Galbraith wrote:Calculating these values at runtime would have been completely insane, the alternative would be a crummy approximation, so using a lookup table is actually a good thing. That's not the problem. BTW could someone please verify the prio_to_wmult table, especially [16] and [21] look a little off, like a digit was cut off. While I'm at this, the 10% scaling there looks a little much (unless there are other changes I haven't looked at yet), the old code used more like 5%. This would mean a prio -20 task would get 98.86% cpu time compared to a prio 0 task, that was previously about the difference between -20 and 19 (and it would have previously gotten only 88.89%), now a prio -20 task would get 99.98% cpu time compared to a prio 19 task. The individual levels are unfortunately not that easily comparable, but at the overall scale the change looks IMHO a little drastic. bye, Roman -
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 006/196] Chinese: add translation of oops-tracing.txt |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
| YOSHIFUJI Hideaki / | request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1) |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Ben Greear | Re: MACVLANs really best solution? How about a bridge with multiple bridge virtual... |
| Rafael J. Wysocki | 2.6.29-rc8: Reported regressions from 2.6.28 |
