From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Con Kolivas <kernel@kolivas.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC] CPU scheduler: Simplified interactive bonus mechanism
Date: Thu, 29 Dec 2005 19:22:05 +1100 [thread overview]
Message-ID: <43B39CAD.9040002@yahoo.com.au> (raw)
In-Reply-To: <43B35D43.40902@bigpond.net.au>
Peter Williams wrote:
> Nick Piggin wrote:
>> Back on topic: I don't think that this patch isn't clearly
>
>
> I assume that the double negative here is accidental and you mean that
> this scheduler isn't clearly better than the current one.
>
Yep.
>> better than what currently exists, nor would require less
>> testing than any other large scale changes to the scheduler
>> behaviour.
>>
>> So, as Con seems to imply, it is JASW (just another scheduler
>> rewrite).
>
>
> Not a rewrite just some major surgery to one small part (at least when
> compared to nicksched, staircase and the SPA schedulers). This doesn't
> effect the run queue structure or the load balancing mechanisms. Or,
Well, the runqueue structure is the "easy" part of it. And load balancing
should not be changed at all[*] by any of these things because we are talking
about a per-CPU runqueue model.
[*] Apart from obvious and really hard to analyse things like which task is
actually running at a point in time, and changing the cache-hotness of
things...
> for that matter, even the bonus mechanism itself other than the
> calculation of the bonus as the way the bonus is applied once calculated
> is unchanged.
>
OK maybe it isn't as large scale a change as one of the rewrites, however
it still is going to probably wildly change behaviour of situations outside
the little box you analysed and found it to be an improvement for.
But points to you for experimenting and trying new things. Don't let me
put you off because I'm not much of an expert on ingosched so it may not
be as large a change as I'm making it out to be.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2005-12-29 8:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-28 6:24 [RFC] CPU scheduler: Simplified interactive bonus mechanism Peter Williams
2005-12-28 6:35 ` Con Kolivas
2005-12-28 7:47 ` Nick Piggin
2005-12-29 3:51 ` Peter Williams
2005-12-29 8:02 ` Ingo Molnar
2005-12-29 8:22 ` Nick Piggin [this message]
2005-12-28 8:00 ` Ingo Molnar
2005-12-28 8:36 ` Ingo Molnar
2005-12-28 13:16 ` Peter Williams
2006-01-03 0:55 ` Peter Williams
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=43B39CAD.9040002@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pwil3058@bigpond.net.au \
/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