sched: fix GENTLE_FAIR_SLEEPERS dependency [Kernel]

Prev: vmscan: more simplify shrink_inactive_list()
Next: mxc: Add board support for the i.MX51 babbage board

From: Suresh Jayaraman on 4 Dec 2009 06:50

On 12/04/2009 04:38 PM, Peter Zijlstra wrote:
> On Fri, 2009-12-04 at 15:50 +0530, Suresh Jayaraman wrote:
>>
>> I think originally introduced as a development/debugging facility,
>> sched_features is slowly transforming into a viable tool for System
>> Administrators, by looking at the impact of turning on/off some of these
>> features on some workloads (especially non-desktop workloads). And I
>> think these benefits should be passed on to the end users perhaps in the
>> form of documentation.
>
> This is really not meant to be used in that context. Its purely a debug
> feature, with knobs coming and going as we see fit.
>

Does this also mean these features should not impact any specific
workload much?

http://osdir.com/ml/linux-kernel/2009-09/msg03406.html
In the thread above Ingo mentions about a few features and my
understanding is that some of these might favour one type of workload
than other. Is this not true anymore?

Thanks,

--
Suresh Jayaraman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Peter Zijlstra on 4 Dec 2009 07:10

On Fri, 2009-12-04 at 17:12 +0530, Suresh Jayaraman wrote:
> On 12/04/2009 04:38 PM, Peter Zijlstra wrote:
> > On Fri, 2009-12-04 at 15:50 +0530, Suresh Jayaraman wrote:
> >>
> >> I think originally introduced as a development/debugging facility,
> >> sched_features is slowly transforming into a viable tool for System
> >> Administrators, by looking at the impact of turning on/off some of these
> >> features on some workloads (especially non-desktop workloads). And I
> >> think these benefits should be passed on to the end users perhaps in the
> >> form of documentation.
> >
> > This is really not meant to be used in that context. Its purely a debug
> > feature, with knobs coming and going as we see fit.
> >
>
> Does this also mean these features should not impact any specific
> workload much?

How would that follow?

> http://osdir.com/ml/linux-kernel/2009-09/msg03406.html
> In the thread above Ingo mentions about a few features and my
> understanding is that some of these might favour one type of workload
> than other. Is this not true anymore?

Sure it is, everything is workload dependent, the posix SCHED_OTHER task
model just doesn't include much usable information.

But that does not justify promoting this to generic tunable. What if you
happen to want to run two different workloads on one machine?

Its a CONFIG_SCHED_DEBUG thing, its in /debug (i've got a patch lined up
to remove the sysctl interface already), and I'm not going to guarantee
any kind of stability in the feature set what so ever.

Furthermore, if your favourite workload doesn't work well, file a bug
report (preferably with reproducer, otherwise its pure guesswork).

The only reason to poke at it is debugging, full stop, no whining or .33
won't have the interface anymore, which would be sad because then
everybody will have to recompile their kernel to debug things.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Suresh Jayaraman on 4 Dec 2009 08:20

On 12/04/2009 05:38 PM, Peter Zijlstra wrote:
> On Fri, 2009-12-04 at 17:12 +0530, Suresh Jayaraman wrote:
>> On 12/04/2009 04:38 PM, Peter Zijlstra wrote:
>>> On Fri, 2009-12-04 at 15:50 +0530, Suresh Jayaraman wrote:
>>>>
>>>> I think originally introduced as a development/debugging facility,
>>>> sched_features is slowly transforming into a viable tool for System
>>>> Administrators, by looking at the impact of turning on/off some of these
>>>> features on some workloads (especially non-desktop workloads). And I
>>>> think these benefits should be passed on to the end users perhaps in the
>>>> form of documentation.
>>>
>>> This is really not meant to be used in that context. Its purely a debug
>>> feature, with knobs coming and going as we see fit.
>>>
>>
>> Does this also mean these features should not impact any specific
>> workload much?
>
> How would that follow?
>
>> http://osdir.com/ml/linux-kernel/2009-09/msg03406.html
>> In the thread above Ingo mentions about a few features and my
>> understanding is that some of these might favour one type of workload
>> than other. Is this not true anymore?
>
> Sure it is, everything is workload dependent, the posix SCHED_OTHER task
> model just doesn't include much usable information.
>
> But that does not justify promoting this to generic tunable. What if you
> happen to want to run two different workloads on one machine?

Ok, I understand.

>
> Furthermore, if your favourite workload doesn't work well, file a bug
> report (preferably with reproducer, otherwise its pure guesswork).

Make sense.

> The only reason to poke at it is debugging, full stop, no whining or .33
> won't have the interface anymore, which would be sad because then
> everybody will have to recompile their kernel to debug things.
>

The intention was to understand better (if at all there is anything
tunable, if yes document) and definitely not whining. Please don't kill it.

Thanks,

--
Suresh Jayaraman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Mike Galbraith on 4 Dec 2009 08:20

First | Prev |
Pages: 1 2
Prev: vmscan: more simplify shrink_inactive_list()
Next: mxc: Add board support for the i.MX51 babbage board