[ Added LKML ]
On Tue, 2011-02-15 at 13:17 -0800, [email protected] 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 <[email protected]> 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 <[email protected]>
> Date: Thu, 10 Feb 2011 10:21:08 +0100
> Subject: sched: Give CPU bound RT tasks preference
>
> From:: Steven Rostedt <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Peter Zijlstra <[email protected]>
> Cc: Gregory Haskins <[email protected]>
> LKML-Reference: <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Mike Galbraith <[email protected]>
> Acked-by: Peter Zijlstra <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> 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 [email protected] are
On Tue, Feb 15, 2011 at 06:02:47PM -0500, Steven Rostedt wrote:
> [ Added LKML ]
>
> On Tue, 2011-02-15 at 13:17 -0800, [email protected] 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 <[email protected]> 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 <[email protected]>
> > Date: Thu, 10 Feb 2011 10:21:08 +0100
> > Subject: sched: Give CPU bound RT tasks preference
> >
> > From:: Steven Rostedt <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Peter Zijlstra <[email protected]>
> > Cc: Gregory Haskins <[email protected]>
> > LKML-Reference: <[email protected]>
> > Signed-off-by: Ingo Molnar <[email protected]>
> > Signed-off-by: Mike Galbraith <[email protected]>
> > Acked-by: Peter Zijlstra <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > 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 [email protected] are
>
On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
> [ Added LKML ]
>
> On Tue, 2011-02-15 at 13:17 -0800, [email protected] 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 <[email protected]> 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
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
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, [email protected] 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 <[email protected]> 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
* Mike Galbraith <[email protected]> wrote:
> On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
> > [ Added LKML ]
> >
> > On Tue, 2011-02-15 at 13:17 -0800, [email protected] 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 <[email protected]> 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
On 02/16/2011 09:25 AM, Ingo Molnar wrote:
>
> * Mike Galbraith <[email protected]> wrote:
>
>> On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
>>> [ Added LKML ]
>>>
>>> On Tue, 2011-02-15 at 13:17 -0800, [email protected] 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 <[email protected]> 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
[ about -stable merge policy ]
* Jiri Slaby <[email protected]> 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
On Wed, 2011-02-16 at 09:55 +0100, Jiri Slaby wrote:
> On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> >
> > * Mike Galbraith <[email protected]> wrote:
> >
> >> On Tue, 2011-02-15 at 18:02 -0500, Steven Rostedt wrote:
> >>> [ Added LKML ]
> >>>
> >>> On Tue, 2011-02-15 at 13:17 -0800, [email protected] 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 <[email protected]> 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
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/
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
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
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/
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
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/