lkml.org 
[lkml]   [2008]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 6/6] sched: disabled rt-bandwidth by default

On Thu, 28 Aug 2008, 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.
>
> 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.

I guess the reason that this is getting so much noise over other default
policies, is that this default policy is changing a well known definition:
The meaning of FIFO.

By making the default policy limit the time an RT task runs, we have, in
essence, changed a user API. Applications that expect to be able to run
uninterrupted by SCHED_OTHER tasks, will now break.

No one is arguing that this new feature is not useful. The argument is,
should the kernel set the default policy of an old well known scheduling
policy to something different than what is expected?

Distros set SE Linux on by default, should the kernel do that too?

-- Steve



\
 
 \ /
  Last update: 2008-08-28 20:13    [W:0.353 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site