public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: Kirill Korotaev <dev@sw.ru>
Cc: vatsa@in.ibm.com, riel@redhat.com, Ingo Molnar <mingo@elte.hu>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] Fair-user scheduler
Date: Fri, 26 Jan 2007 19:52:49 +0100	[thread overview]
Message-ID: <45BA4E01.6050303@tremplin-utc.net> (raw)
In-Reply-To: <45BA0B7C.1090304@sw.ru>

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 fair allocation for all users in a system.
>>
>> Some benchmark numbers with and without the patch applied follows:
>>
>>
>> 		 	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+fairsched	766.74s (real)		   766.73s (real)
> 1. If I interpret these numbers correctly, then your scheduler is not work-conservative,
> i.e. 766.74 + 766.73 >> 472.07 + 257.48
> why does it slow down users so much?
You can't measure work-conservation by summing! Everything is ran 
_concurrently_. A proof of losing computing power is to show 
"MAX(new_algorithm execution_times) > MAX(old_algorithm 
execution_times)". Anyway... it still seems lots of power is lost: 
MAX(766,766) >> MAX(472,257).

Actually, I'd be very interested by a "fairness number" and believe so 
far no one as proposed such thing. Probably needs to take into account 
the loss of CPU power and the variance of execution time in between the 
sets of tasks which are supposed to be fair.

> 2. compilation of kernel is quite CPU-bound task. So it's not that hard to be fair :)
>    Can you please try some other applications?
>    e.g. pipe-based context switching, java Volano benchmark etc.
Another worthy benchmark would be :
(make -s -j4 bzImage) vs (nice make -s -j20 bzImage)
                           ^^^^


Regards,
Eric

  reply	other threads:[~2007-01-26 19:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-26  6:01 [RFC] Fair-user scheduler Srivatsa Vaddagiri
2007-01-26  6:03 ` [PATCH 1/2] core scheduler changes Srivatsa Vaddagiri
2007-01-31 15:01   ` Srivatsa Vaddagiri
2007-01-26  6:05 ` [PATCH 2/2] Track number of users in the system Srivatsa Vaddagiri
2007-01-26 14:09 ` [RFC] Fair-user scheduler Kirill Korotaev
2007-01-26 18:52   ` Eric Piel [this message]
2007-01-31 15:10     ` Srivatsa Vaddagiri
2007-01-26 18:41 ` Chris Friesen
2007-01-31 15:16   ` Srivatsa Vaddagiri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45BA4E01.6050303@tremplin-utc.net \
    --to=eric.piel@tremplin-utc.net \
    --cc=akpm@osdl.org \
    --cc=dev@sw.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=riel@redhat.com \
    --cc=vatsa@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox