Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Steven Rostedt]

[ Added LKML ]

On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
> This is a note to let you know that I've just added the patch titled
> 
>     sched: Give CPU bound RT tasks preference
> 
> to the 2.6.32-longterm tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
> 
> The filename of the patch is:
>      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
> and it can be found in the queue-2.6.32 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
> please let <stable@kernel.org> know about it.
> 
> 

I don't mind this patch being added to the long term tree. But I'm
curious about what is the criteria for adding changes to it? This is a
performance improvement and not a critical bug fix.

-- Steve

> >From 10db390cadda977081a7a34f60b8ce62557521c9 Mon Sep 17 00:00:00 2001
> From: stable-bot for Steven Rostedt <srostedt@redhat.com>
> Date: Thu, 10 Feb 2011 10:21:08 +0100
> Subject: sched: Give CPU bound RT tasks preference
> 
> From:: Steven Rostedt <srostedt@redhat.com>
> 
> Commit: b3bc211cfe7d5fe94b310480d78e00bea96fbf2a upstream
> 
> If a high priority task is waking up on a CPU that is running a
> lower priority task that is bound to a CPU, see if we can move the
> high RT task to another CPU first. Note, if all other CPUs are
> running higher priority tasks than the CPU bounded current task,
> then it will be preempted regardless.
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Gregory Haskins <ghaskins@novell.com>
> LKML-Reference: <20100921024138.888922071@goodmis.org>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> ---
>  kernel/sched_rt.c |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> --- a/kernel/sched_rt.c
> +++ b/kernel/sched_rt.c
> @@ -965,7 +965,8 @@ select_task_rq_rt(struct rq *rq, struct
>  	 * For equal prio tasks, we just let the scheduler sort it out.
>  	 */
>  	if (unlikely(rt_task(rq->curr)) &&
> -	    rq->curr->prio < p->prio &&
> +	    (rq->curr->rt.nr_cpus_allowed < 2 ||
> +	     rq->curr->prio < p->prio) &&
>  	    (p->rt.nr_cpus_allowed > 1)) {
>  		int cpu = find_lowest_rq(p);
>  
> @@ -1493,9 +1494,10 @@ static void task_woken_rt(struct rq *rq,
>  	if (!task_running(rq, p) &&
>  	    !test_tsk_need_resched(rq->curr) &&
>  	    has_pushable_tasks(rq) &&
> +	    p->rt.nr_cpus_allowed > 1 &&
>  	    rt_task(rq->curr) &&
> -	    rq->curr->prio < p->prio &&
> -	    p->rt.nr_cpus_allowed > 1)
> +	    (rq->curr->rt.nr_cpus_allowed < 2 ||
> +	     rq->curr->prio < p->prio))
>  		push_rt_tasks(rq);
>  }
>  
> 
> 
> Patches currently in longterm-queue-2.6.32 which might be from srostedt@redhat.com are

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Greg KH]

On Tue, Feb 15, 2011 at 06:02:47PM -0500, Steven Rostedt wrote:
> [ Added LKML ]
> 
> On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
> > This is a note to let you know that I've just added the patch titled
> > 
> >     sched: Give CPU bound RT tasks preference
> > 
> > to the 2.6.32-longterm tree which can be found at:
> >     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
> > 
> > The filename of the patch is:
> >      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
> > and it can be found in the queue-2.6.32 subdirectory.
> > 
> > If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
> > please let <stable@kernel.org> know about it.
> > 
> > 
> 
> I don't mind this patch being added to the long term tree. But I'm
> curious about what is the criteria for adding changes to it? This is a
> performance improvement and not a critical bug fix.

I'll defer to Mike here, as he submitted this series.  I'm pretty sure
it resolves a number of problems reported with the schedular, overall,
with the whole series, right?

Mike?

thanks,

greg k-h


> > >From 10db390cadda977081a7a34f60b8ce62557521c9 Mon Sep 17 00:00:00 2001
> > From: stable-bot for Steven Rostedt <srostedt@redhat.com>
> > Date: Thu, 10 Feb 2011 10:21:08 +0100
> > Subject: sched: Give CPU bound RT tasks preference
> > 
> > From:: Steven Rostedt <srostedt@redhat.com>
> > 
> > Commit: b3bc211cfe7d5fe94b310480d78e00bea96fbf2a upstream
> > 
> > If a high priority task is waking up on a CPU that is running a
> > lower priority task that is bound to a CPU, see if we can move the
> > high RT task to another CPU first. Note, if all other CPUs are
> > running higher priority tasks than the CPU bounded current task,
> > then it will be preempted regardless.
> > 
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Gregory Haskins <ghaskins@novell.com>
> > LKML-Reference: <20100921024138.888922071@goodmis.org>
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > Signed-off-by: Mike Galbraith <efault@gmx.de>
> > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > ---
> >  kernel/sched_rt.c |    8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > --- a/kernel/sched_rt.c
> > +++ b/kernel/sched_rt.c
> > @@ -965,7 +965,8 @@ select_task_rq_rt(struct rq *rq, struct
> >  	 * For equal prio tasks, we just let the scheduler sort it out.
> >  	 */
> >  	if (unlikely(rt_task(rq->curr)) &&
> > -	    rq->curr->prio < p->prio &&
> > +	    (rq->curr->rt.nr_cpus_allowed < 2 ||
> > +	     rq->curr->prio < p->prio) &&
> >  	    (p->rt.nr_cpus_allowed > 1)) {
> >  		int cpu = find_lowest_rq(p);
> >  
> > @@ -1493,9 +1494,10 @@ static void task_woken_rt(struct rq *rq,
> >  	if (!task_running(rq, p) &&
> >  	    !test_tsk_need_resched(rq->curr) &&
> >  	    has_pushable_tasks(rq) &&
> > +	    p->rt.nr_cpus_allowed > 1 &&
> >  	    rt_task(rq->curr) &&
> > -	    rq->curr->prio < p->prio &&
> > -	    p->rt.nr_cpus_allowed > 1)
> > +	    (rq->curr->rt.nr_cpus_allowed < 2 ||
> > +	     rq->curr->prio < p->prio))
> >  		push_rt_tasks(rq);
> >  }
> >  
> > 
> > 
> > Patches currently in longterm-queue-2.6.32 which might be from srostedt@redhat.com are
> 

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Mike Galbraith]

On Tue, 2011-02-15 at 15:32 -0800, Greg KH wrote:
> On Tue, Feb 15, 2011 at 06:02:47PM -0500, Steven Rostedt wrote:
> > [ Added LKML ]
> > 
> > On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
> > > This is a note to let you know that I've just added the patch titled
> > > 
> > >     sched: Give CPU bound RT tasks preference
> > > 
> > > to the 2.6.32-longterm tree which can be found at:
> > >     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
> > > 
> > > The filename of the patch is:
> > >      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
> > > and it can be found in the queue-2.6.32 subdirectory.
> > > 
> > > If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
> > > please let <stable@kernel.org> know about it.
> > > 
> > > 
> > 
> > I don't mind this patch being added to the long term tree. But I'm
> > curious about what is the criteria for adding changes to it? This is a
> > performance improvement and not a critical bug fix.
> 
> I'll defer to Mike here, as he submitted this series.  I'm pretty sure
> it resolves a number of problems reported with the schedular, overall,
> with the whole series, right?
> 
> Mike?

This particular patch was purely about performance.  The general thrust
of the series is of course about getting reported issues fixed.  We've
got bug reports, and I'm sure everyone else does too.

	-Mike

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Mike Galbraith]

On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
> [ Added LKML ]
> 
> On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
> > This is a note to let you know that I've just added the patch titled
> > 
> >     sched: Give CPU bound RT tasks preference
> > 
> > to the 2.6.32-longterm tree which can be found at:
> >     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
> > 
> > The filename of the patch is:
> >      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
> > and it can be found in the queue-2.6.32 subdirectory.
> > 
> > If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
> > please let <stable@kernel.org> know about it.
> > 
> > 
> 
> I don't mind this patch being added to the long term tree. But I'm
> curious about what is the criteria for adding changes to it? This is a
> performance improvement and not a critical bug fix.

Yes, I added it for the performance.  .32-stable is enterprise beans and
biscuits.  Same reason I added the load balancing fixes, boxen won't
explode without them, but load balancing performs better with them.

	-Mike

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Steven Rostedt]

On Wed, 2011-02-16 at 03:01 +0100, Mike Galbraith wrote:

> > I don't mind this patch being added to the long term tree. But I'm
> > curious about what is the criteria for adding changes to it? This is a
> > performance improvement and not a critical bug fix.
> 
> Yes, I added it for the performance.  .32-stable is enterprise beans and
> biscuits.  Same reason I added the load balancing fixes, boxen won't
> explode without them, but load balancing performs better with them.

Thanks for clarifying.

-- Steve

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
> > [ Added LKML ]
> > 
> > On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
> > > This is a note to let you know that I've just added the patch titled
> > > 
> > >     sched: Give CPU bound RT tasks preference
> > > 
> > > to the 2.6.32-longterm tree which can be found at:
> > >     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
> > > 
> > > The filename of the patch is:
> > >      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
> > > and it can be found in the queue-2.6.32 subdirectory.
> > > 
> > > If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
> > > please let <stable@kernel.org> know about it.
> > > 
> > > 
> > 
> > I don't mind this patch being added to the long term tree. But I'm
> > curious about what is the criteria for adding changes to it? This is a
> > performance improvement and not a critical bug fix.
> 
> Yes, I added it for the performance.  .32-stable is enterprise beans and
> biscuits.  Same reason I added the load balancing fixes, boxen won't
> explode without them, but load balancing performs better with them.

We try to concentrate on regression fixes though. So performance enhancements
should only be queued up if they fix problems bad enough that could rightfully
be sent to Linus in an -rc5+ timeframe as well.

This patch is borderline i guess so i have no problems with it - but we should be 
somewhat more conservative about this in the future.

Thanks,

	Ingo

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Jiri Slaby]

On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> 
> * Mike Galbraith <efault@gmx.de> wrote:
> 
>> On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
>>> [ Added LKML ]
>>>
>>> On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
>>>> This is a note to let you know that I've just added the patch titled
>>>>
>>>>     sched: Give CPU bound RT tasks preference
>>>>
>>>> to the 2.6.32-longterm tree which can be found at:
>>>>     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
>>>>
>>>> The filename of the patch is:
>>>>      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
>>>> and it can be found in the queue-2.6.32 subdirectory.
>>>>
>>>> If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
>>>> please let <stable@kernel.org> know about it.
>>>>
>>>>
>>>
>>> I don't mind this patch being added to the long term tree. But I'm
>>> curious about what is the criteria for adding changes to it? This is a
>>> performance improvement and not a critical bug fix.
>>
>> Yes, I added it for the performance.  .32-stable is enterprise beans and
>> biscuits.  Same reason I added the load balancing fixes, boxen won't
>> explode without them, but load balancing performs better with them.
> 
> We try to concentrate on regression fixes though.

Hi, I cannot fully agree with this. The question is who are "we" here?
If every packager using this stable tree is forced by users/customers to
take it anyway, it's better to have it in stable.

It has several reasons:
* It will have an eye of experts on them. Not that at distro providers
there are no experts, but the authors who are cced here know definitely
the code better.
* Not every packager has to duplicate others work.
* The stable tree changes constantly. Managing hundreds of patches
applied to a stable tree before kernels are being packaged is thus
sometimes a hell. Reducing this number is a good thing(TM).

regards,
-- 
js

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Ingo Molnar]

[ about -stable merge policy ]

* Jiri Slaby <jirislaby@gmail.com> wrote:

> > We try to concentrate on regression fixes though.
> 
> Hi, I cannot fully agree with this. The question is who are "we" here?

It's the upstream policy and the scheduler tree certainly follows it.

I think i remember Linus having stated it before (cannot find the mail), but it's 
pretty common-sense so easy to reproduce (i've Cc:-ed Linus in case he wants to 
chime in):

   The idea is to treat Linus's tree and -stable as an organic whole: so -stable
   is upstream as well, but with *bug* fixes backported. It's emphatically not a 
   separate "for backporting interesting/important bits" tree.

   And as such whatever a maintainer can send to Linus in -rc's (in particular late
   -rc's) is -stable eligible.

   For the rest of patches: generally not eligible, but with common-sense 
   exceptions.

   "It's a nice patch" or "it will obviously not cause problems" or "this is
   important to us" does not make a patch eligible for -stable.

   Adding a -stable tag to a commit and *not* sending it to Linus for the next -rc
   also makes a patch almost automatically *not* eligible: if it was not important
   enough to have it in the next -rc then it's doubly not eligible for -stable ...

   I think this common-sense rule is easy to follow:

    " If you ever have to ask yourself whether a patch queued up for -stable is 
      really -stable eligible it probably isnt. "

   It's called -stable for a reason.

Thanks,

	Ingo

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Mike Galbraith]

On Wed, 2011-02-16 at 09:55 +0100, Jiri Slaby wrote:
> On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> > 
> > * Mike Galbraith <efault@gmx.de> wrote:
> > 
> >> On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
> >>> [ Added LKML ]
> >>>
> >>> On Tue, 2011-02-15 at 13:17 -0800, gregkh@suse.de wrote:
> >>>> This is a note to let you know that I've just added the patch titled
> >>>>
> >>>>     sched: Give CPU bound RT tasks preference
> >>>>
> >>>> to the 2.6.32-longterm tree which can be found at:
> >>>>     http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
> >>>>
> >>>> The filename of the patch is:
> >>>>      0006-sched-Give-CPU-bound-RT-tasks-preference.patch
> >>>> and it can be found in the queue-2.6.32 subdirectory.
> >>>>
> >>>> If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
> >>>> please let <stable@kernel.org> know about it.
> >>>>
> >>>>
> >>>
> >>> I don't mind this patch being added to the long term tree. But I'm
> >>> curious about what is the criteria for adding changes to it? This is a
> >>> performance improvement and not a critical bug fix.
> >>
> >> Yes, I added it for the performance.  .32-stable is enterprise beans and
> >> biscuits.  Same reason I added the load balancing fixes, boxen won't
> >> explode without them, but load balancing performs better with them.
> > 
> > We try to concentrate on regression fixes though.
> 
> Hi, I cannot fully agree with this. The question is who are "we" here?
> If every packager using this stable tree is forced by users/customers to
> take it anyway, it's better to have it in stable.
> 
> It has several reasons:
> * It will have an eye of experts on them. Not that at distro providers
> there are no experts, but the authors who are cced here know definitely
> the code better.
> * Not every packager has to duplicate others work.
> * The stable tree changes constantly. Managing hundreds of patches
> applied to a stable tree before kernels are being packaged is thus
> sometimes a hell. Reducing this number is a good thing(TM).

Fully agree on all fronts, but it's a hard call.  When I start auditing,
I sweat bullets.  I see piles of bug fixes, and piles of performance
enhancements, all of which are ever so tempting, all of which are worthy
of backport.. but humans _are_ buggy, so there is risk involved.

	-Mike

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Stefan Richter]

On Feb 16 Mike Galbraith wrote:
> On Wed, 2011-02-16 at 09:55 +0100, Jiri Slaby wrote:
> > On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> > > We try to concentrate on regression fixes though.
> > 
> > Hi, I cannot fully agree with this. The question is who are "we" here?
> > If every packager using this stable tree is forced by users/customers to
> > take it anyway, it's better to have it in stable.
> > 
> > It has several reasons:
> > * It will have an eye of experts on them. Not that at distro providers
> > there are no experts, but the authors who are cced here know definitely
> > the code better.
> > * Not every packager has to duplicate others work.
> > * The stable tree changes constantly. Managing hundreds of patches
> > applied to a stable tree before kernels are being packaged is thus
> > sometimes a hell. Reducing this number is a good thing(TM).
> 
> Fully agree on all fronts, but it's a hard call.  When I start auditing,
> I sweat bullets.  I see piles of bug fixes, and piles of performance
> enhancements, all of which are ever so tempting, all of which are worthy
> of backport.. but humans _are_ buggy, so there is risk involved.

Jiri,
if the desire is to improve performance of existing features (and maybe
add this and that little feature that looks attractive), while at the same
time you want
  - experts to have looked at these improvements,
  - packagers to avoid duplicate work,
  - keep the number of local patches in check,
then the solution is to /stay close enough to the mainline/.

Unstable -longterm trees (unstable as in having a high rate of changes,
possibly as in having frequent regressions) are for sure an alternative
solution that those who use these trees apparently do consider.  But if
regressions avoidance is not their top priority, what other reason do they
have to follow -longterm instead of the mainline?

(Says a mainline user, and a driver maintainer who has pushed his share of
occasional regressions to -stable branches but hopes to constantly get
better at regression avoidance.)
-- 
Stefan Richter
-=====-==-== --=- =----
http://arcgraph.de/sr/

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Mike Galbraith]

On Wed, 2011-02-16 at 15:29 +0100, Stefan Richter wrote:
> On Feb 16 Mike Galbraith wrote:
> > On Wed, 2011-02-16 at 09:55 +0100, Jiri Slaby wrote:
> > > On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> > > > We try to concentrate on regression fixes though.
> > > 
> > > Hi, I cannot fully agree with this. The question is who are "we" here?
> > > If every packager using this stable tree is forced by users/customers to
> > > take it anyway, it's better to have it in stable.
> > > 
> > > It has several reasons:
> > > * It will have an eye of experts on them. Not that at distro providers
> > > there are no experts, but the authors who are cced here know definitely
> > > the code better.
> > > * Not every packager has to duplicate others work.
> > > * The stable tree changes constantly. Managing hundreds of patches
> > > applied to a stable tree before kernels are being packaged is thus
> > > sometimes a hell. Reducing this number is a good thing(TM).
> > 
> > Fully agree on all fronts, but it's a hard call.  When I start auditing,
> > I sweat bullets.  I see piles of bug fixes, and piles of performance
> > enhancements, all of which are ever so tempting, all of which are worthy
> > of backport.. but humans _are_ buggy, so there is risk involved.
> 
> Jiri,
> if the desire is to improve performance of existing features (and maybe
> add this and that little feature that looks attractive), while at the same
> time you want
>   - experts to have looked at these improvements,
>   - packagers to avoid duplicate work,
>   - keep the number of local patches in check,
> then the solution is to /stay close enough to the mainline/.

That's the intent of pushing more than _purely_ critical bugfixes, get a
bit closer.  Enterprise can't move as fast as mainline, not even close,
that's a given.  Stable problem get griped about though, so there's no
choice but to take some risk.  The tricky bit is how much, and how you
go about it.

People are fixing this and that in their enterprise kernels privately
every day.  The only difference between that, and pushing baked fixes
back is that pushing to stable is visible.  I strongly suspect that
there are just tons of mainline backports sitting in each and every
enterprise tree in existence.  They could have been pushed to stable,
with _less_ stability risk, due to the higher visibility.

Just my opinion.  Oh, and critical eye is definitely good, that's why I
posted to stable after all ;-)

	-Mike

Re: [stable] Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Willy Tarreau]

Hi Mike,

On Thu, Feb 17, 2011 at 06:05:07AM +0100, Mike Galbraith wrote:
> That's the intent of pushing more than _purely_ critical bugfixes, get a
> bit closer.  Enterprise can't move as fast as mainline, not even close,
> that's a given.  Stable problem get griped about though, so there's no
> choice but to take some risk.  The tricky bit is how much, and how you
> go about it.
> 
> People are fixing this and that in their enterprise kernels privately
> every day.  The only difference between that, and pushing baked fixes
> back is that pushing to stable is visible.  I strongly suspect that
> there are just tons of mainline backports sitting in each and every
> enterprise tree in existence.  They could have been pushed to stable,
> with _less_ stability risk, due to the higher visibility.

I can confirm that my local 2.6.27 tree has had a quite number of sched
updates that were posted by Ingo, Peter or You in the last two years,
and I'll definitely be considering your work for future updates. However
we must be very careful about what we include in -stable. Its primary
purpose precisely is to let every user upgrade without checking what was
merged because we are responsible for ensuring there is no regression. I
would say it's already a bit late in the 2.6.32 cycle for that but we're
in the first half of its lifecycle and it has a lot of users, so that
would still benefit a lot of people. Let's just hope it will not break
any workload (eg: double the time it takes for a specific task) otherwise
-stable and -longterm will lose some trust among enterprise users.

Ideally we should just make a stable release with just enhancements
from time to time, without important fixes so that people can revert
to the previous one and alert us in case of trouble. But my feeling
is that the current version more or less matches that goal, I don't
remember having seen anything really critical in it that can't be
reverted in case of trouble.

So let's have it, tell users to report any issue and move on :-)

Regards,
Willy

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Stefan Richter]

On Feb 17 Mike Galbraith wrote:
> On Wed, 2011-02-16 at 15:29 +0100, Stefan Richter wrote:
> > Jiri,
> > if the desire is to improve performance of existing features (and maybe
> > add this and that little feature that looks attractive), while at the same
> > time you want
> >   - experts to have looked at these improvements,
> >   - packagers to avoid duplicate work,
> >   - keep the number of local patches in check,
> > then the solution is to /stay close enough to the mainline/.

[By which I meant updating, not backporting.]

> That's the intent of pushing more than _purely_ critical bugfixes, get a
> bit closer.  Enterprise can't move as fast as mainline, not even close,
> that's a given.  Stable problem get griped about though, so there's no
> choice but to take some risk.  The tricky bit is how much, and how you
> go about it.

Granted.

> People are fixing this and that in their enterprise kernels privately
> every day.  The only difference between that, and pushing baked fixes
> back is that pushing to stable is visible.  I strongly suspect that
> there are just tons of mainline backports sitting in each and every
> enterprise tree in existence.

'Visible' = the change which was an important performance improvement or
outright fix at site A (and a nice-to-have improvement on sites B...X)
eventually exhibits a regression at site Y.
-- 
Stefan Richter
-=====-==-== --=- =---=
http://arcgraph.de/sr/

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Mike Galbraith]

On Thu, 2011-02-17 at 08:52 +0100, Stefan Richter wrote:
> On Feb 17 Mike Galbraith wrote:
> > On Wed, 2011-02-16 at 15:29 +0100, Stefan Richter wrote:
> > > Jiri,
> > > if the desire is to improve performance of existing features (and maybe
> > > add this and that little feature that looks attractive), while at the same
> > > time you want
> > >   - experts to have looked at these improvements,
> > >   - packagers to avoid duplicate work,
> > >   - keep the number of local patches in check,
> > > then the solution is to /stay close enough to the mainline/.
> 
> [By which I meant updating, not backporting.]

[but you know that ain't an option too]

> > People are fixing this and that in their enterprise kernels privately
> > every day.  The only difference between that, and pushing baked fixes
> > back is that pushing to stable is visible.  I strongly suspect that
> > there are just tons of mainline backports sitting in each and every
> > enterprise tree in existence.
> 
> 'Visible' = the change which was an important performance improvement or
> outright fix at site A (and a nice-to-have improvement on sites B...X)
> eventually exhibits a regression at site Y.

Known bugs are stable bugs, known performance problems are stable
performance problems is the only answer to that.  Leaving them as is
does remove risk of a customer satisfaction delta.. but..  

But whatever.  Yeah, I understand that it's a sticky wicket.

	-Mike

Re: Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

[Stefan Richter]

On Feb 17 Mike Galbraith wrote:
> On Thu, 2011-02-17 at 08:52 +0100, Stefan Richter wrote:
> > > > then the solution is to /stay close enough to the mainline/.
> > 
> > [By which I meant updating, not backporting.]
> 
> [but you know that ain't an option too]

Could be disputed for any use case in which performance backports are an
option in the first place.
-- 
Stefan Richter
-=====-==-== --=- =---=
http://arcgraph.de/sr/