[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160401063348.GA6815@gmail.com>
Date: Fri, 1 Apr 2016 08:33:48 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Michal Hocko <mhocko@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
"David S. Miller" <davem@...emloft.net>,
Tony Luck <tony.luck@...el.com>,
Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>, x86@...nel.org,
linux-alpha@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
linux-arch@...r.kernel.org
Subject: Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Thu, 31 Mar 2016 11:20:05 +0200 Ingo Molnar <mingo@...nel.org> wrote:
>
> > So AFAIK Andrew's tree is based on top of linux-next
>
> Not really true any more - I only base -mm patches on linux-next
> patches when they must be based that way due to some known dependency.
>
> I can certainly handle MM patches which are based on linux-next. Such
> an arrangement is going to make life awkward for Michal's
> auto-maintained git tree of the -mm MM patches
> (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git).
>
> Maybe I could merge down_write_killable into -mm's main MM section then
> knock it out of my copy of linux-next, so everything is seamless for
> mm.git. I've done that before.
>
> But it's all a bit of a pain - it would be simpler to keep
> down_write_killable in the same tree as the patches which depend on it.
I can help on the Git level: I can do tip:locking/rwsem tree with only these
changes, with stable sha1's, on which the remaining work can be based. The
locking tree typically goes in early during the merge window, so there's no
real dependencies.
On the source code level this series is changing the existing locking code too,
it doesn't just add a new orthogonal method or so, so I'd really like to have
it in the locking tree.
Thanks,
Ingo
Powered by blists - more mailing lists