public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Con Kolivas <kernel@kolivas.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC] CPU scheduler: Simplified interactive bonus mechanism
Date: Tue, 03 Jan 2006 11:55:42 +1100	[thread overview]
Message-ID: <43B9CB8E.7050405@bigpond.net.au> (raw)
In-Reply-To: <20051228083615.GA12180@elte.hu>

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>* Peter Williams <pwil3058@bigpond.net.au> wrote:
>>
>>
>>>This patch implements a prototype version of a simplified interactive 
>>>bonus mechanism.  The mechanism does not attempt to identify 
>>>interactive tasks and give them a bonus (like the current mechanism 
>>>does) but instead attacks the problem that the bonuses are supposed to 
>>>fix, unacceptable interactive latency, directly.
>>
>>i think we could give this one a workout in -mm, to see the actual 
>>effects. Would you mind to merge this to -mm's scheduler queue, to right 
>>after sched-add-sched_batch-policy.patch?
> 
> 
> i have done this for latest -mm, see the patch below (i also merged your 
> patch to the SCHED_BATCH patch's effects), but the resulting kernel has 
> really bad interactivity: e.g. simply starting 4 CPU hogs on a 2-CPU 
> system slows down shell commands like 'ls' noticeably. So NACK for the 
> time being.

I've just realized a more serious reason why this scheduler modification 
needs to be postponed as unsuitable for general use.  It essentially 
relies on sched_clock() having at least microsecond resolution and it 
has been pointed out to me that on some systems this isn't true and, 
even though its units are always nanoseconds, the resolution of 
sched_clock() can be large as 1/HZ.  This scheduler would not work very 
well on these systems so its time has not yet come regardless of 
successful resolution of the other problems.

Nevertheless, I'll add a scheduler based on ingosched with this 
modification (and fixes) to PlugSched so that progress can be made on 
improving it for those systems where it is feasible.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

      parent reply	other threads:[~2006-01-03  0:55 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
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 [this message]

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=43B9CB8E.7050405@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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