On Fri, Jan 26, 2007 at 12:41:27PM -0600, Chris Friesen wrote:
> As Kirill brought up, why does it take so much more time? Are you
> thrashing the cache?
Yes, the default 1-sec control window I had was causing lot of
thrashing. See http://lkml.org/lkml/2007/1/31/142
> Presumably this would be m
On Fri, Jan 26, 2007 at 07:52:49PM +0100, Eric Piel wrote:
> >>user "vatsa"user "guest"
> >>(make -s -j4 bzImage) (make -s -j20 bzImage)
> >>
> >>2.6.20-rc5 472.07s (real) 257.48s (real)
> >>2.6.20-rc5+fairsched76
01/26/2007 03:09 PM, Kirill Korotaev wrote/a écrit:
Srivatsa,
Current Linux CPU scheduler doesnt recognize process aggregates while
allocating bandwidth. As a result of this, an user could simply spawn large
number of processes and get more bandwidth than others.
Here's a patch that provides
Srivatsa Vaddagiri wrote:
Current Linux CPU scheduler doesnt recognize process aggregates while
allocating bandwidth. As a result of this, an user could simply spawn large
number of processes and get more bandwidth than others.
Here's a patch that provides fair allocation for all users in a sy
Srivatsa,
> Current Linux CPU scheduler doesnt recognize process aggregates while
> allocating bandwidth. As a result of this, an user could simply spawn large
> number of processes and get more bandwidth than others.
>
> Here's a patch that provides fair allocation for all users in a system.
>
Current Linux CPU scheduler doesnt recognize process aggregates while
allocating bandwidth. As a result of this, an user could simply spawn large
number of processes and get more bandwidth than others.
Here's a patch that provides fair allocation for all users in a system.
Some benchmark numbers
6 matches
Mail list logo
