From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-Netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
David Miller <davem@davemloft.net>, Neil Brown <neilb@suse.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Mike Christie <michaelc@cs.wisc.edu>,
Eric B Munson <emunson@mgebm.net>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH 04/16] mm: allow PF_MEMALLOC from softirq context
Date: Mon, 9 Jul 2012 18:57:10 +0200 [thread overview]
Message-ID: <20120709165710.GC3515@breakpoint.cc> (raw)
In-Reply-To: <20120709100442.GZ14154@suse.de>
On Mon, Jul 09, 2012 at 11:04:42AM +0100, Mel Gorman wrote:
> > - lets assume your allocation happens with kmalloc() without __GFP_MEMALLOC
> > and current->flags has PF_MEMALLOC ORed and your SLAB pool is empty. This
> > forces SLAB to allocate more pages from the buddy allocator with it will
> > receive more likely (due to ->current->flags + PF_MEMALLOC) but SLAB will
> > drop this extra memory because the page has ->pf_memory (or something like
> > that) set and the GFP_FLAGS do not have __GFP_MEMALLOC set.
> >
>
> It's recorded if the slab page was allocated from PFMEMALLOC reserves (see
> patch 2 from the swap over NBD series). slab will use this page for objects
> but only allocate them to callers that pass a gfp_pfmemalloc_allowed() check.
> kmalloc() users with either __GFP_MEMALLOC or PF_MEMALLOC will get
> the pages they need but they will not "leak" to !_GFP_MEMALLOC users as
> that would potentially deadlock.
Argh, I missed that gfp_to_alloc_flags() is not only called from
within the buddy allocater but also from slab. So this is fine then :)
One thing:
You only get current->flags |= PF_MEMALLOC in softirq _if_ the skb, which is
passed to netif_receive_skb(), was allocated with __GFP_MEMALLOC. That
means if the NIC's RX allocation did not require an allocation from the
emergency pool (without ->pfmemalloc set) then you never use this extra
pool, even if this skb would end up in your swap socket. Also, the other way
around, where you allocate it from the emergency pool but it is a user
socket and you could drop it.
What about extending sk_set_memalloc() to record socket's ips + ports
in a separate list so that skb_pfmemalloc_protocol() might use that
information and decide on per-protocol basis if the skb is worth to
spend more ressource to deliver it. That means you would enable the
extra pool if the currently received skb is part of your swap socket and
not if the skb was allocated from the emergency pool.
That said, there is nothing wrong with the code as of now and this
optimization could be added later (if at all).
Sebastian
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-07-09 16:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 14:30 [PATCH 00/17] Swap-over-NBD without deadlocking V13 Mel Gorman
2012-06-22 14:30 ` [PATCH 01/16] mm: sl[au]b: Add knowledge of PFMEMALLOC reserve pages Mel Gorman
2012-06-22 14:30 ` [PATCH 02/16] mm: slub: Optimise the SLUB fast path to avoid pfmemalloc checks Mel Gorman
2012-06-22 14:30 ` [PATCH 03/16] mm: Introduce __GFP_MEMALLOC to allow access to emergency reserves Mel Gorman
2012-06-22 14:30 ` [PATCH 04/16] mm: allow PF_MEMALLOC from softirq context Mel Gorman
2012-06-26 16:55 ` Sebastian Andrzej Siewior
2012-06-27 8:26 ` Mel Gorman
2012-07-08 18:12 ` Sebastian Andrzej Siewior
2012-07-09 10:04 ` Mel Gorman
2012-07-09 16:57 ` Sebastian Andrzej Siewior [this message]
2012-07-10 11:09 ` Mel Gorman
2012-06-22 14:30 ` [PATCH 05/16] mm: Only set page->pfmemalloc when ALLOC_NO_WATERMARKS was used Mel Gorman
2012-06-22 14:30 ` [PATCH 06/16] mm: Ignore mempolicies when using ALLOC_NO_WATERMARK Mel Gorman
2012-06-22 14:30 ` [PATCH 07/16] net: Introduce sk_gfp_atomic() to allow addition of GFP flags depending on the individual socket Mel Gorman
2012-06-22 14:30 ` [PATCH 08/16] netvm: Allow the use of __GFP_MEMALLOC by specific sockets Mel Gorman
2012-06-22 14:30 ` [PATCH 09/16] netvm: Allow skb allocation to use PFMEMALLOC reserves Mel Gorman
2012-06-26 15:27 ` Sebastian Andrzej Siewior
2012-06-27 8:32 ` Mel Gorman
2012-06-22 14:30 ` [PATCH 10/16] netvm: Propagate page->pfmemalloc to skb Mel Gorman
2012-06-22 14:30 ` [PATCH 11/16] netvm: Propagate page->pfmemalloc from skb_alloc_page " Mel Gorman
2012-06-26 20:13 ` Sebastian Andrzej Siewior
2012-06-27 8:43 ` Mel Gorman
2012-07-09 19:18 ` Sebastian Andrzej Siewior
2012-07-10 11:12 ` Mel Gorman
2012-06-22 14:30 ` [PATCH 12/16] netvm: Set PF_MEMALLOC as appropriate during SKB processing Mel Gorman
2012-06-22 14:30 ` [PATCH 13/16] mm: Micro-optimise slab to avoid a function call Mel Gorman
2012-06-22 14:30 ` [PATCH 14/16] nbd: Set SOCK_MEMALLOC for access to PFMEMALLOC reserves Mel Gorman
2012-06-22 14:30 ` [PATCH 15/16] mm: Throttle direct reclaimers if PF_MEMALLOC reserves are low and swap is backed by network storage Mel Gorman
2012-06-22 14:30 ` [PATCH 16/16] mm: Account for the number of times direct reclaimers get throttled Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2012-06-29 13:32 [PATCH 00/16] Swap-over-NBD without deadlocking V14 Mel Gorman
2012-06-29 13:32 ` [PATCH 04/16] mm: allow PF_MEMALLOC from softirq context Mel Gorman
2012-07-12 6:40 [PATCH 00/16] Swap-over-NBD without deadlocking V15 Mel Gorman
2012-07-12 6:40 ` [PATCH 04/16] mm: allow PF_MEMALLOC from softirq context Mel Gorman
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=20120709165710.GC3515@breakpoint.cc \
--to=sebastian@breakpoint.cc \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=emunson@mgebm.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--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).