[lkml]   [2003]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.0-test2-mm1 results
On Fri, 1 Aug 2003 00:56, Martin J. Bligh wrote:
> --Con Kolivas <> wrote (on Thursday, July 31, 2003
01:28:49 +1000):
> > On Thu, 31 Jul 2003 01:01, Martin J. Bligh wrote:
> >> OK, so test2-mm1 fixes the panic I was seeing in test1-mm1.
> >> Only noticeable thing is that -mm tree is consistently a little slower
> >> at kernbench
> >
> > Could conceivably be my hacks throwing the cc cpu hogs onto the expired
> > array more frequently.
> Kernbench: (make -j vmlinux, maximal tasks)
> Elapsed System User CPU
> 2.6.0-test2 46.05 115.20 571.75 1491.25
> 2.6.0-test2-con 46.98 121.02 583.55 1498.75
> 2.6.0-test2-mm1 46.95 121.18 582.00 1497.50
> Good guess ;-)
> Does this help interactivity a lot, or was it just an experiment?
> Perhaps it could be less agressive or something?

Well basically this is a side effect of selecting out the correct cpu hogs in
the interactivity estimator. It seems to be working ;-) The more cpu hogs
they are the lower dynamic priority (higher number) they get, and the more
likely they are to be removed from the active array if they use up their full
timeslice. The scheduler in it's current form costs more to resurrect things
from the expired array and restart them, and the cpu hogs will have to wait
till other less cpu hogging tasks run.

How do we get around this? I'll be brave here and say I'm not sure we need to,
as cpu hogs have a knack of slowing things down for everyone, and it is best
not just for interactivity for this to happen, but for fairness.

I suspect a lot of people will have something to say on this one...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.111 / U:3.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site