From: Daniel Phillips <phillips@phunq.net>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org, trond.myklebust@fys.uio.no
Subject: Re: [PATCH 03/29] mm: slb: add knowledge of reserve pages
Date: Fri, 14 Dec 2007 14:51:09 -0800 [thread overview]
Message-ID: <200712141451.09500.phillips@phunq.net> (raw)
In-Reply-To: <20071214154439.242195000@chello.nl>
On Friday 14 December 2007 07:39, Peter Zijlstra wrote:
> Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to
> allocation contexts that are entitled to it. This is done to ensure
> reserve pages don't leak out and get consumed.
Tighter definitions of "leak out" and "get consumed" would be helpful
here. As I see it, the chain of reasoning is:
* Any MEMALLOC mode allocation must have come from a properly
throttled path and has a finite lifetime that must eventually
produce writeout progress.
* Since the transaction that made the allocation was throttled and
must have a finite lifetime, we know that it must eventually return
the resources it consumed to the appropriate resource pool.
Now, I think what you mean by "get consumed" and "leak out" is: "become
pinned by false sharing with other allocations that do not guarantee
that they will be returned to the resource pool". We can say "pinned"
for short.
So you are attempting to prevent slab pages from becoming pinned by
users that do not obey the reserve management rules, which I think your
approach achieves. However...
Note that false sharing of slab pages is still possible between two
unrelated writeout processes, both of which obey rules for their own
writeout path, but the pinned combination does not. This still leaves
a hole through which a deadlock may slip.
My original solution was simply to allocate a full page when drawing
from the memaloc reserve, which may use a tad more reserve, but makes
it possible to prove the algorithm correct.
Regards,
Daniel
--
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:[~2007-12-14 22:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-14 15:39 [PATCH 00/29] Swap over NFS -v15 Peter Zijlstra
2007-12-14 15:39 ` [PATCH 01/29] mm: gfp_to_alloc_flags() Peter Zijlstra
2007-12-14 15:39 ` [PATCH 02/29] mm: tag reseve pages Peter Zijlstra
2007-12-14 15:39 ` [PATCH 03/29] mm: slb: add knowledge of reserve pages Peter Zijlstra
2007-12-14 22:51 ` Daniel Phillips [this message]
2007-12-15 10:10 ` Daniel Phillips
2007-12-14 15:39 ` [PATCH 04/29] mm: kmem_estimate_pages() Peter Zijlstra
2007-12-14 22:05 ` Daniel Phillips
2007-12-14 15:39 ` [PATCH 05/29] mm: allow PF_MEMALLOC from softirq context Peter Zijlstra
2007-12-14 15:39 ` [PATCH 06/29] mm: serialize access to min_free_kbytes Peter Zijlstra
2007-12-14 15:39 ` [PATCH 07/29] mm: emergency pool Peter Zijlstra
2007-12-14 15:39 ` [PATCH 08/29] mm: system wide ALLOC_NO_WATERMARK Peter Zijlstra
2007-12-14 15:39 ` [PATCH 09/29] mm: __GFP_MEMALLOC Peter Zijlstra
2007-12-14 15:39 ` [PATCH 10/29] mm: memory reserve management Peter Zijlstra
2007-12-14 15:39 ` [PATCH 11/29] selinux: tag avc cache alloc as non-critical Peter Zijlstra
2007-12-14 15:39 ` [PATCH 12/29] net: wrap sk->sk_backlog_rcv() Peter Zijlstra
2007-12-14 15:39 ` [PATCH 13/29] net: packet split receive api Peter Zijlstra
2007-12-14 15:39 ` [PATCH 14/29] net: sk_allocation() - concentrate socket related allocations Peter Zijlstra
2007-12-14 15:39 ` [PATCH 15/29] netvm: network reserve infrastructure Peter Zijlstra
2007-12-14 15:39 ` [PATCH 16/29] netvm: INET reserves Peter Zijlstra
2007-12-14 21:10 ` Daniel Phillips
2007-12-14 15:39 ` [PATCH 17/29] netvm: hook skb allocation to reserves Peter Zijlstra
2007-12-14 15:39 ` [PATCH 18/29] netvm: filter emergency skbs Peter Zijlstra
2007-12-14 15:39 ` [PATCH 19/29] netvm: prevent a TCP specific deadlock Peter Zijlstra
2007-12-14 15:39 ` [PATCH 20/29] netfilter: NF_QUEUE vs emergency skbs Peter Zijlstra
2007-12-14 15:39 ` [PATCH 21/29] netvm: skb processing Peter Zijlstra
2007-12-14 15:39 ` [PATCH 22/29] mm: prepare swap entry methods for use in page methods Peter Zijlstra
2007-12-14 15:39 ` [PATCH 23/29] mm: add support for non block device backed swap files Peter Zijlstra
2007-12-14 15:39 ` [PATCH 24/29] mm: methods for teaching filesystems about PG_swapcache pages Peter Zijlstra
2007-12-14 15:39 ` [PATCH 25/29] nfs: remove mempools Peter Zijlstra
2007-12-14 15:39 ` [PATCH 26/29] nfs: teach the NFS client how to treat PG_swapcache pages Peter Zijlstra
2007-12-14 15:39 ` [PATCH 27/29] nfs: disable data cache revalidation for swapfiles Peter Zijlstra
2007-12-14 15:39 ` [PATCH 28/29] nfs: enable swap on NFS Peter Zijlstra
2007-12-14 15:39 ` [PATCH 29/29] nfs: fix various memory recursions possible with swap over NFS Peter Zijlstra
2007-12-14 21:07 ` [PATCH 00/29] Swap over NFS -v15 Daniel Phillips
2007-12-19 22:22 ` Bill Davidsen
2007-12-20 8:00 ` Peter Zijlstra
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=200712141451.09500.phillips@phunq.net \
--to=phillips@phunq.net \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trond.myklebust@fys.uio.no \
/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