netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Miller <davem@davemloft.net>,
	linux-mm@kvack.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, neilb@suse.de,
	a.p.zijlstra@chello.nl, michaelc@cs.wisc.edu, emunson@mgebm.net
Subject: Re: [PATCH 00/17] Swap-over-NBD without deadlocking V10
Date: Mon, 14 May 2012 12:10:58 +0100	[thread overview]
Message-ID: <20120514111058.GC29102@suse.de> (raw)
In-Reply-To: <20120511142932.af7851bd.akpm@linux-foundation.org>

On Fri, May 11, 2012 at 02:29:32PM -0700, Andrew Morton wrote:
> On Fri, 11 May 2012 17:23:39 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Mel Gorman <mgorman@suse.de>
> > Date: Fri, 11 May 2012 16:45:40 +0100
> > 
> > > From my point of view, the ideal would be that all the patches go
> > > through akpm's tree or yours but that probably will cause merge
> > > difficulties.
> > > 
> > > Any recommendations?
> > 
> > I know there will be networking side conflicts very soon, it's not a
> > matter of 'if' but 'when'.
> > 
> > But the trick is that I bet the 'mm' and 'slab' folks are in a similar
> > situation.
> > 
> > In any event I'm more than happy to take it all in my tree.
> 
> I guess either is OK.  The main thing is to get it all reviewed and
> tested, after all.
> 
> I can take all the patches once it's all lined up and everyone is
> happy.  If the net bits later take significant damage then I can squirt them
> at you once the core MM bits are merged.  That would give you a few
> days to check them over and get them into Linus.  If that's a problem,
> we can hold the net bits over for a cycle.
> 
> That's all assuming that the core MM parts are mergeable without the
> net parts being merged.  I trust that's the case!

I expect it to be the case as the series is (or at least should be)
bisect safe. If there is a conflict of some sort, just cut off at that
point and it should be fine until it gets fixed up.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2012-05-14 11:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-10 13:44 [PATCH 00/17] Swap-over-NBD without deadlocking V10 Mel Gorman
2012-05-10 13:44 ` [PATCH 01/17] mm: Serialize access to min_free_kbytes Mel Gorman
2012-05-10 13:44 ` [PATCH 02/17] mm: sl[au]b: Add knowledge of PFMEMALLOC reserve pages Mel Gorman
2012-05-10 13:44 ` [PATCH 03/17] mm: slub: Optimise the SLUB fast path to avoid pfmemalloc checks Mel Gorman
2012-05-10 13:44 ` [PATCH 04/17] mm: Introduce __GFP_MEMALLOC to allow access to emergency reserves Mel Gorman
2012-05-10 13:44 ` [PATCH 05/17] mm: allow PF_MEMALLOC from softirq context Mel Gorman
2012-05-11  4:39   ` David Miller
2012-05-14 10:02     ` Mel Gorman
2012-05-15 13:07       ` Mel Gorman
2012-05-10 13:44 ` [PATCH 06/17] mm: Only set page->pfmemalloc when ALLOC_NO_WATERMARKS was used Mel Gorman
2012-05-10 13:45 ` [PATCH 07/17] mm: Ignore mempolicies when using ALLOC_NO_WATERMARK Mel Gorman
2012-05-10 13:45 ` [PATCH 08/17] net: Introduce sk_allocation() to allow addition of GFP flags depending on the individual socket Mel Gorman
2012-05-11  4:49   ` David Miller
2012-05-11 14:12     ` Mel Gorman
2012-05-10 13:45 ` [PATCH 09/17] netvm: Allow the use of __GFP_MEMALLOC by specific sockets Mel Gorman
2012-05-11  4:50   ` David Miller
2012-05-10 13:45 ` [PATCH 10/17] netvm: Allow skb allocation to use PFMEMALLOC reserves Mel Gorman
2012-05-11  4:57   ` David Miller
2012-05-11 14:32     ` Mel Gorman
2012-05-11 14:42       ` Peter Zijlstra
2012-05-11 15:07         ` Mel Gorman
2012-05-11 21:17       ` David Miller
2012-05-10 13:45 ` [PATCH 11/17] netvm: Propagate page->pfmemalloc to skb Mel Gorman
2012-05-10 13:45 ` [PATCH 12/17] netvm: Propagate page->pfmemalloc from netdev_alloc_page " Mel Gorman
2012-05-11  5:01   ` David Miller
2012-05-11 14:46     ` Mel Gorman
2012-05-10 13:45 ` [PATCH 13/17] netvm: Set PF_MEMALLOC as appropriate during SKB processing Mel Gorman
2012-05-11  5:03   ` David Miller
2012-05-10 13:45 ` [PATCH 14/17] mm: Micro-optimise slab to avoid a function call Mel Gorman
2012-05-10 13:45 ` [PATCH 15/17] nbd: Set SOCK_MEMALLOC for access to PFMEMALLOC reserves Mel Gorman
2012-05-10 13:45 ` [PATCH 16/17] mm: Throttle direct reclaimers if PF_MEMALLOC reserves are low and swap is backed by network storage Mel Gorman
2012-05-10 13:45 ` [PATCH 17/17] mm: Account for the number of times direct reclaimers get throttled Mel Gorman
2012-05-10 17:17 ` [PATCH 00/17] Swap-over-NBD without deadlocking V10 Mike Christie
2012-05-11  5:04 ` David Miller
2012-05-11 15:45   ` Mel Gorman
2012-05-11 21:23     ` David Miller
2012-05-11 21:29       ` Andrew Morton
2012-05-14 11:10         ` Mel Gorman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120514111058.GC29102@suse.de \
    --to=mgorman@suse.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=emunson@mgebm.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=neilb@suse.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).