lkml.org 
[lkml]   [2005]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFA: Changing scheduler quantum (Was: REQUEST: OpenLDAP 2.3.7)
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.

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:

[pid 8780] 0.000033 stat64("gidNumber.dbb", 0xb7b3ebcc) = -1 EACCES (Permission denied)
[pid 8780] 0.000059 pread(20, "\0\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344\17\2\3"..., 4096, 4096) = 4096
[pid 8780] 0.000083 pread(20, "\0\0\0\0\1\0\0\0\4\0\0\0\3\0\0\0\0\0\0\0\222\0<\7\1\5\370"..., 4096, 16384) = 4096
[pid 8780] 0.000078 time(NULL) = 1124322520
[pid 8780] 0.000066 pread(11, "\0\0\0\0\1\0\0\0\250\0\0\0\231\0\0\0\235\0\0\0\16\0000"..., 4096, 688128) = 4096
[pid 8780] 0.000241 write(19, "0e\2\1\3d`\4$cn=bernie,ou=group,dc=d"..., 103) = 103
[pid 8780] 0.000137 sched_yield( <unfinished ...>
...zzzz...
[pid 8781] 0.050020 <... sched_yield resumed> ) = 0
[pid 8780] 0.000025 <... sched_yield resumed> ) = 0
[pid 8781] 0.000060 futex(0x925ab20, FUTEX_WAIT, 33, NULL <unfinished ...>
[pid 8780] 0.000026 write(19, "0\f\2\1\3e\7\n\1\0\4\0\4\0", 14) = 14
[pid 8774] 0.000774 <... select resumed> ) = 1 (in [19])


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.

--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/

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

\
 
 \ /
  Last update: 2005-09-18 23:56    [W:0.038 / U:1.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site