All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] optional non-interactive mode for cpu scheduler
Date: Wed, 03 Nov 2004 00:02:04 +1100	[thread overview]
Message-ID: <4187854C.6000803@kolivas.org> (raw)
In-Reply-To: <20041102125218.GH15290@elte.hu>

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

Ingo Molnar wrote:
> * Con Kolivas <kernel@kolivas.org> wrote:
> 
> 
>>optional non-interactive mode for cpu scheduler
> 
> 
> i think the following scheme would work better:
> 
>  - introduce a new SCHED_CPUBOUND policy
>  - return ->static_prio + 5 for such tasks
>  - keep their timeslice based off ->static_prio
> 
> the point is this: such tasks would thus be automatically and
> perpetually considered 'CPU hogs'. Applications cannot abuse this
> mechanism because they get the maximum 'penalty'.
> 
> and as a bonus, no magic sysctl and inherently more flexibility.
> 
> (note that this scheme has advantages above nice +5 because nice +5
> still has the interactivity stuff on which can create priority
> fluctuations and may thus affect workloads.)
> 
> if you agree with this scheme, would you be interested in implementing
> this?

The better cpu proportion guarantee without low latency of such a policy 
would be desirable to video encoding in the background while capturing 
in the foreground as one immediately recognisable purpose, and there are 
likely numerous others, so I agree it's a good idea.

However the non-interactive mode addresses a number of different needs 
that seem to have come up. Specifically:
I have had users report great success with such a mode on my own 
scheduler in multiple X session setups where very choppy behaviour 
occurs in mainline.
Many high performance computing people do not wish interactivity code 
modifying their choice of latency/distribution - admittedly this is a 
soft one.

What are your thoughts on this?

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  reply	other threads:[~2004-11-02 13:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-02  5:31 [PATCH] optional non-interactive mode for cpu scheduler Con Kolivas
2004-11-02 12:52 ` Ingo Molnar
2004-11-02 13:02   ` Con Kolivas [this message]
2004-11-02 13:11     ` Ingo Molnar
2004-11-02 13:40       ` Con Kolivas
2004-11-02 13:52         ` Ingo Molnar
2004-11-02 17:17           ` Kyle Moffett
2004-11-03  9:16           ` Con Kolivas

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=4187854C.6000803@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.