[lkml]   [2003]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] self tuning scheduler
Hi Mike

I made a bit of progress on understanding the irman problem with
my scheduler change. When I run irman and top, the processes end
up with priorities like:

irman parent 36
irman child 21
process_child 31-33 (group of 9 processes)

Since I expanded the range of priorities (to 0-79) these are quite
favorable priorities. They are all have MAX_SLEEP_AVG bonus
equivelent of nice +10.

It's a priority inversion problem. The irman child is waiting for
a read. The process_child processes are happly running as a group
at approximately the same priority. The irman parent is starved
because it is at a lower priority. It is at a lower priority because
it uses more cpu on each pass. It is doing the gettimeofday calls
while the child only does the pipe read & write. The parent gets
an occasional boost from the fairness_update() code so it doesn't
totally starve.

I'm contemplating making synchronous wakeups share the run_avg between
the processes so that groups of cooperating processes would clump
at the same priority.

I also wonder about trying to detect cycles of synchronous wakeups.
It seems that a group of processes passing a token should be treated as
compute bound.

I'm still playing with the "make -j 30". I can adjust the priority
range where I start enforcing interactive behavior. I may wire it
into the rq->prio_avg. I assume that you can tolerate a bit more
timing jitter when doing a "make -j 30".

Jim Houston - Concurrent Computer Corp.
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:33    [W:0.034 / U:7.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site