[Fwd: Interesting analysis of linux kernel threading by IBM]

From: Duane Hanf (hanfactuarial@uswest.net)
Date: Fri Jan 21 2000 - 12:14:43 EST


I am receiving emails from all over the country (130 so far to day) that
are not addressesd to me. The only thing they have in common is the the
messages are either sent to or copied in to the following email address:
linux-kernel@vger.rutgers.edu
Please remove my email address from this group.
Please notify me of your action. Thank you.


attached mail follows:


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.



-
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/

-
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/



This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:25 EST