public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	LKML <linux-kernel@vger.kernel.org>,
	Stefani Seibold <stefani@seibold.net>,
	Dario Faggioli <raistlin@linux.it>,
	Max Krasnyansky <maxk@qualcomm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 6/6] sched: disabled rt-bandwidth by default
Date: Sat, 30 Aug 2008 16:33:23 +1000	[thread overview]
Message-ID: <200808301633.23764.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <alpine.LFD.1.10.0808281024060.3300@nehalem.linux-foundation.org>

On Friday 29 August 2008 03:26, Linus Torvalds wrote:
> On Thu, 28 Aug 2008, Steven Rostedt wrote:
> > I've always thought that the policy settings belong in the distro, and
> > the kernel should never enforce a policy (by setting this as default, it
> > is enforcing a policy, even though an RT user can change it).
>
> The kernel has always done a certain amount of "default policy".
>
> What do you think things like "swappiness" etc are? Or things like
> oevrcommit settings? They're all policies, and there is always a default
> one. So in that sense the kernel always has - and fundamentally _must_ -
> set some kind of policy.

There is a difference. You *have* to pick some value for those things.
The settings can't necessarily be called correct or incorrect.

The default rt sched policy is definitely "broken" in that it very clearly
changes our previous behaviour, documentation, and what other systems do.

You could say that "realtime" in general is not really a single accepted
definition, but *SCHED_FIFO* and *SCHED_RR* in particular do have a well
defined, simple, and widely accepted definition that is undeniably changed
by this "policy".

Given that a) we can easily introduce new SCHED_xxx policies to implement
the new behaviour, and b) there are quite a few users of this API in this
thread who are concerned about the change, I think it is wisest just to
revert to our old behaviour.

I thought the rule of thumb is "if in doubt, we don't break user APIs".
It's funny that nobody has really answered any of my points of concern.

Anyway, I won't keep harping on about it.


> And the default policy should generally be the one that makes sense for
> most people. Quite frankly, if it's an issue where all normal distros
> would basically be expected to set a value, then that value should _be_
> the default policy, and none of the normal distros should ever need to
> worry.
>
> Whether this case is one such, I dunno. Quite frankly, I don't think it's
> even _nearly_ important enough to get this kind of noise.

That's cause you don't care about rt that much. You do care about back
compatibility though so I thought you'd be more interested. Anyway, I won't
post any more.

  parent reply	other threads:[~2008-08-30  6:33 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-19 10:33 [PATCH 0/6] sched: rt-bandwidth fixes Peter Zijlstra
2008-08-19 10:33 ` [PATCH 1/6] sched: rt-bandwidth for user grouping interface Peter Zijlstra
2008-08-19 10:33 ` [PATCH 2/6] sched: rt-bandwidth accounting fix Peter Zijlstra
2008-08-19 18:33   ` Max Krasnyansky
2008-08-19 18:38     ` Peter Zijlstra
2008-08-19 10:33 ` [PATCH 3/6] sched: rt-bandwidth group disable fixes Peter Zijlstra
2008-08-19 10:33 ` [PATCH 4/6] sched: extract walk_tg_tree() Peter Zijlstra
2008-08-19 10:33 ` [PATCH 5/6] sched: rt-bandwidth fixes Peter Zijlstra
2008-08-19 10:33 ` [PATCH 6/6] sched: disabled rt-bandwidth by default Peter Zijlstra
2008-08-19 11:05   ` Ingo Molnar
2008-08-19 11:11     ` Ingo Molnar
2008-08-19 11:42       ` [PATCH] sched: extract walk_tg_tree(), fix Ingo Molnar
2008-08-19 11:17     ` [PATCH 6/6] sched: disabled rt-bandwidth by default Nick Piggin
2008-08-19 12:59       ` Ingo Molnar
2008-08-19 18:15         ` Max Krasnyansky
2008-08-20 11:56         ` Nick Piggin
2008-08-26  9:00           ` Nick Piggin
2008-08-26  9:30             ` Ingo Molnar
2008-08-26  9:44               ` Nick Piggin
2008-08-26 10:29                 ` Ingo Molnar
2008-08-26 11:03                   ` Nick Piggin
2008-08-26  9:54               ` Nick Piggin
2008-08-26 11:09                 ` Thomas Gleixner
2008-08-26 11:27                   ` Nick Piggin
2008-08-26 12:50                     ` Theodore Tso
2008-08-26 13:31                       ` Stefani Seibold
2008-08-26 17:55                         ` Theodore Tso
2008-08-26 21:37                     ` Thomas Gleixner
2008-08-26 22:49                       ` Andi Kleen
2008-08-27 10:08                         ` Nick Piggin
2008-08-28 10:54                           ` Ingo Molnar
2008-08-28 11:09                             ` Andi Kleen
2008-08-28 11:19                               ` Peter Zijlstra
2008-08-28 11:28                                 ` Ingo Molnar
2008-08-28 11:50                                 ` Andi Kleen
2008-08-28 12:00                                   ` Peter Zijlstra
2008-08-28 12:14                                     ` Andi Kleen
2008-08-28 12:18                                       ` Nick Piggin
2008-08-28 16:19                                   ` Max Krasnyansky
2008-08-28 16:25                                     ` Ingo Molnar
2008-08-28 16:33                                       ` Andi Kleen
2008-08-28 12:03                             ` Nick Piggin
2008-08-28 13:07                               ` Ingo Molnar
2008-08-28 13:45                                 ` Nick Piggin
2008-08-28 12:29                             ` Nick Piggin
2008-08-27 10:04                       ` Nick Piggin
2008-08-26 13:47                   ` Mark Hounschell
2008-08-26 23:00                     ` Steven Rostedt
2008-08-27 18:55                       ` Chris Friesen
2008-08-28 14:15     ` Steven Rostedt
2008-08-28 14:30       ` Ingo Molnar
2008-08-28 14:36         ` Nick Piggin
2008-08-28 15:12           ` Steven Rostedt
2008-08-28 15:34             ` Nick Piggin
2008-08-28 15:50               ` Steven Rostedt
2008-08-28 17:26                 ` Linus Torvalds
2008-08-28 18:04                   ` Steven Rostedt
2008-08-28 18:10                     ` Darren Hart
2008-08-28 18:16                   ` Mark Hounschell
2008-08-28 18:42                     ` Linus Torvalds
2008-08-28 18:53                       ` Steven Rostedt
2008-08-29  7:56                         ` Mike Galbraith
2008-08-29  8:06                           ` Peter Zijlstra
2008-08-29  8:47                             ` Mike Galbraith
2008-08-28 19:39                       ` Stefani Seibold
2008-08-28 20:53                       ` Alan Cox
2008-08-30  6:33                   ` Nick Piggin [this message]
2008-08-28 16:33           ` Max Krasnyansky
2008-08-28 17:22             ` John Kacur
2008-08-28 16:05       ` Peter Zijlstra
2008-08-28 16:15         ` Steven Rostedt
2008-08-28 16:29           ` Peter Zijlstra

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=200808301633.23764.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxk@qualcomm.com \
    --cc=mingo@elte.hu \
    --cc=raistlin@linux.it \
    --cc=rostedt@goodmis.org \
    --cc=stefani@seibold.net \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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