From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755555AbdGKIaV (ORCPT <rfc822;w@1wt.eu>);
        Tue, 11 Jul 2017 04:30:21 -0400
Received: from mail-wr0-f175.google.com ([209.85.128.175]:34433 "EHLO
        mail-wr0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1755409AbdGKIaS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 11 Jul 2017 04:30:18 -0400
Date: Tue, 11 Jul 2017 10:30:14 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Ben Guthro <ben@guthro.net>
Cc: Greg KH <gregkh@linuxfoundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Mike Galbraith <efault@gmx.de>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Potential scheduler regression
Message-ID: <20170711083014.jpdpcbo6rlh5uuti@gmail.com>
References: <CAOvdn6UhFUG-NDBf5P9EqS+6UA6LCeDTw1aBbW-dbzPU3Z4T1A@mail.gmail.com>
 <20170705164850.lnziwloc6mko3mxo@hirez.programming.kicks-ass.net>
 <CAOvdn6WHAqnyr4WFz3ogA8FAueVcASJGYZOBjit=diMud7N4mw@mail.gmail.com>
 <20170710092532.kzwgukzishwpzoq6@hirez.programming.kicks-ass.net>
 <20170710152629.GB13980@kroah.com>
 <CAOvdn6U0cFStU0-Sh=NkjNqjDW=y4iy_S7x0t=jnw__eY1ahOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOvdn6U0cFStU0-Sh=NkjNqjDW=y4iy_S7x0t=jnw__eY1ahOA@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Ben Guthro <ben@guthro.net> wrote:

> > If people have experience with these in the "enterprise" distros, or any other 
> > tree, and want to provide me with backported, and tested, patches, I'll be 
> > glad to consider them for stable kernels.
> >
> > thanks,
> >
> > greg k-h
> 
> I tried to do a simple cherry-pick of the suggested patches - but they
> apply against files that don't exist in the 4.9 series.

I think there are only two strategies to maintain a backport which work in the 
long run:

 - insist on the simplest fixes and pure cherry-picks

 - or pick up _everything_ to sync up the two versions.

The latter would mean a lot of commits - and I'm afraid it would also involve the 
scheduler header split-up, which literally involves hundreds of files plus 
perpetual build-breakage risk, so it's a no-no.

> In my release of 4.9 - I'm planning on doing the simpler revert of 1b568f0aab 
> that introduced the performance degradation, rather than pulling in lots of code 
> from newer kernels.

That sounds much saner - I'd even Ack that approach for -stable as a special 
exception, than to complicate things with excessive backports.

Thanks,

	Ingo