Interesting analysis of linux kernel threading by IBM

[Davide Libenzi]

Hi Werner,

Thursday, January 20, 2000 7:11 PM
Werner Almesberger <almesber en 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.

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: patch.diff.bz2
Type: application/octet-stream
Size: 4662 bytes
Desc: no disponible
URL: <https://lists.srvr.mx/pipermail/ayuda/attachments/20000122/21876de3/attachment.obj>