![]() | |||||||||||||
Messages in this thread |
Hi Horst,
Thursday, January 20, 2000 1:51 PM
Horst von Brand <vonbrand@pincoya.inf.utfsm.cl> write :
> > my patch has great performance ( 80% with 300 tasks ) with a lot of
tasks
> > and low overhead ( 1.5% with 2 tasks ).> > And my patch has 0.00 optimizations about CPU fetches and Co.
> > IMVHO 1-1.5 % of overhead is a price the we can afford given the
performace
> > with many tasks.> > My patch equals the current implementation with 8 tasks.>> So it is a net loss. This machine here (a personal workstation) has
> typically 1 to 3 running tasks.>> Hondreds of tasks is just not a typical (perhaps even realistic)
> workload.
under a normal switching workload You get the same performance ( perhaps
less than 1% )
but when the game become hard ( in a task-switching sense ) You get a
logarithmic response of the
scheduler as function of the number of processes ( now is linear ).
The numbers are these :
300 running processes ( I say running not in runqueue )
12 up to 35 in runqueue
I get an 83% performance improvement
2 running processes ( that switch at the same rate of 300 )
I get 11% up to 15% performance loss
But the fact is that normally 2 tasks switches at a very lower factor then
300.
The probability that a task get scheduled or require a schedule() call.
I We apply a liner low we get :
15 * 2 / 300 = 0.1 % loss
in a real 2 tasks workload.
IMVHO we can sustain this loss given the results at higher switching
workloads.
Cheers,
Davide.
--
Debian, the freedom in freedom.
-
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/
| ||||||||||||
| Last update: 2005-03-22 13:56 [from the cache] ©2003-2008 | |||||||||||||