Messages in this thread | | | Date | Tue, 11 Mar 2003 18:04:33 -0500 | From | Jim Houston <> | Subject | Re: [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 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/
| |