Messages in this thread | | | From | "Davide Libenzi" <> | Subject | Re: Interesting analysis of linux kernel threading by IBM | Date | Thu, 20 Jan 2000 18:32:17 +0100 |
| |
Hi Werner,
Thursday, January 20, 2000 7:11 PM Werner Almesberger <almesber@lrc.di.epfl.ch> wrote : > Maybe you should give examples of the overall performance for typical > CPU/memory bound loads for the extreme cases. I don't think many > people have a good intuition for how much CPU time their system > actually burns in the scheduler. E.g. -15% overall performance sounds > scary, while -15% on of whatever, say, an MP3 player and a simulation > may leave to the scheduler would be difficult to measure, let alone > notice. > > Also, please be sure to make the distinction between concurrently > running (i.e. on different CPUs), runnable (i.e. wanting to run), and > other processes (i.e. waiting for something else to happen) very > clear. Best if you mention all three categories in each example.
I'm speaking about scheduling times that, as You can see inside the IBM guys ( Ray Bryant and Bill Hartner ) article http://www-4.ibm.com/software/developer/library/java2/index.html waste a great percent of CPU time under high workload, due to the fact that the actual scheduler linear scan the runqueue to find the best task to run. My approach gives a logarithmic response versus the linear of the current. My test suite is poor and is for this reason that I like if someone having a best testing console ( like IBM guys and others I hope ) gives a test to the patch. My Jun99 patch also includes a semaphore wake_up() rewrite that instead releasing all the N processes waiting in the queue for reschedule N-1 of them, it find the best task to release inside the wake_up() function. This patch avoid the peak of N processes flushed into the scheduler. Think about processes waiting for a connection into a socket for example.
This patch is for 2.3.5.
Cheers, Davide.
[unhandled content-type:application/octet-stream] | |