Re: RFA: Changing scheduler quantum (Was: REQUEST: OpenLDAP 2.3.7)

[Con Kolivas]

On Mon, 19 Sep 2005 07:53, Bernardo Innocenti wrote:
> Con Kolivas wrote:
> > On Sun, 18 Sep 2005 21:37, Bernardo Innocenti wrote:
> >>The DEF_TIMESLICE of 400ms looks a bit too gross for
> >>most applications and the maximum 800ms is just
> >>ridicolously high.
> >
> > Not quite.
> >
> > The default timeslice of nice 0 tasks is 100ms. The timeslice is not
> > altered the way you have read sched.c. It is altered thus:
> > 1. For 'nice' levels it varies from 5ms at nice 19 to 800ms at nice -20.
> > 2. For interactive tasks, it is cut up into smaller pieces down to 10ms
> > and round robins with other tasks at the same dynamic priority, but still
> > is based on the nice levels for the full length of cpu time before
> > expiration overall.

Please do not cc mailing lists that reply with the "your email is awaiting 
moderator approval" to lkml.

> I see.  Then there must be something else to explain
> the behavior I'm observing with slapd.
>
> Each and every call to sched_yield() makes the process
> sleep for over *50ms* while a "nice make bootstrap" is
> running in the background:

Why this preoccupation with how long sched_yield takes? We've already 
established that it takes a variable unpredictable (yet long) time for 
SCHED_NORMAL tasks. No, cancel that question or we'll start having people 
tell us what the kernel should do all over again.

You're almost certainly seeing the effect of fork during 'make bootstrap' and 
multiple tasks are running prior to expiration on the active runqueue. 
SCHED_NORMAL tasks that have done sched_yield will yield till nothing is left 
wanting cpu time on the active runqueue.

> Actually, I'm now noticing that several slapd threads were
> involved here.  Depending how strace handles relative
> timestamps of multiple processes, it may mean both 8780 and
> 8781 slept too much or just 8781 did and 8780 was quick.
>
> Any idea?  I'm planning to patch my kernel to print the
> time_slice value in /proc/*/stat.  This way I can check
> it's being computed as intended for both slapd and gcc.

Feel free to do as much checking on kernel code as you like.

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/