Messages in this thread | | | Subject | 2.2.1 scheduler behavior | From | Claude Gamache <> | Date | 18 Feb 1999 12:37:42 -0500 |
| |
Hi,
We have an application made up of 15 processes that interact through shared memories and sockets. Each process computes for a few milliseconds and then pass its data to the next one (a pipeline computation scheme). When a process is done with its computation, it calls pause() to release the CPU, it resumes its computation when its timer interrupt wakes it every 10 milliseconds, if the computation were not completed, we log this as an overrun.
With Kernel 2.0.36 on a Dell dual PII 400 MHz with 256 Mb RAM all process are able to compute within there allocated 10 ms time frame.
With Kernel 2.2.1 on a Dell dual PII 450 MHz with 256 Mb RAM the processes keep overrunning ! (same configuration, same amount of computation). With Kernel 2.0.36 on the Dell dual PII 450 MHz, things are normal (no overruns).
With Kernel 2.2.1, if I change the scheduling policy to FIFO with a priority of 90 to 95, then things improve (there are less overruns). But I observed something strange. If I use the Real Time Clock (/dev/rtc) at 8192 Hz (or any high "enough" frequencies), things improve even more, there are much less overruns for the very same computation.
It looks as if the use of the RTC at high frequencies causes the Kernel scheduler to be executed more often.
Also, with Kernel 2.2.1, I noticed with that a process has a tendency to keep switching from one CPU to another (that process being the only one using a noticeable amount of CPU according to ps and top). With 2.0.36, it almost never switch CPU ! That could explain why performances seems more random with 2.2.1.
In the scheduler, is the PROC_CHANGE_PENALTY is large enough, is it something else ?
Is there something to do to adress this ?
Comments ? Explanations ?
Claude
-- Claude Gamache, CAE Electronique Ltee, 8585 Cote-de-Liesse Saint-Laurent, Quebec, Canada H4T 1G6 Email: cgamache@cae.ca Tel.: (514) 341-2000 x3194, Fax: (514) 734-5612
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |