From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: kosaki.motohiro@jp.fujitsu.com, linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/7] Kill PF_MEMALLOC abuse
Date: Tue, 17 Nov 2009 17:33:48 +0900 (JST) [thread overview]
Message-ID: <20091117172802.3DF4.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0911170004380.1564@chino.kir.corp.google.com>
> On Tue, 17 Nov 2009, KOSAKI Motohiro wrote:
>
> >
> > PF_MEMALLOC have following effects.
> > (1) Ignore zone watermark
> > (2) Don't call reclaim although allocation failure, instead return ENOMEM
> > (3) Don't invoke OOM Killer
> > (4) Don't retry internally in page alloc
> >
> > Some subsystem paid attention (1) only, and start to use PF_MEMALLOC abuse.
> > But, the fact is, PF_MEMALLOC is the promise of "I have lots freeable memory.
> > if I allocate few memory, I can return more much meory to the system!".
> > Non MM subsystem must not use PF_MEMALLOC. Memory reclaim
> > need few memory, anyone must not prevent it. Otherwise the system cause
> > mysterious hang-up and/or OOM Killer invokation.
> >
> > if many subsystem will be able to use emergency memory without any
> > usage rule, it isn't for emergency. it can become empty easily.
> >
> > Plus, characteristics (2)-(4) mean PF_MEMALLOC don't fit to general
> > high priority memory allocation.
> >
> > Thus, We kill all PF_MEMALLOC usage in no MM subsystem.
>
> I agree in principle with removing non-VM users of PF_MEMALLOC, but I
> think it should be left to the individual subsystem maintainers to apply
> or ack since the allocations may depend on the __GFP_NORETRY | ~__GFP_WAIT
> behavior of PF_MEMALLOC. This could be potentially dangerous for a
> PF_MEMALLOC user if allocations made by the kthread, for example, should
> never retry for orders smaller than PAGE_ALLOC_COSTLY_ORDER or block on
> direct reclaim.
if there is so such reason. we might need to implement another MM trick.
but keeping this strage usage is not a option. All memory freeing activity
(e.g. page out, task killing) need some memory. we need to protect its
emergency memory. otherwise linux reliability decrease dramatically when
the system face to memory stress.
--
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:[~2009-11-17 8:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 7:16 KOSAKI Motohiro
2009-11-17 7:17 ` [PATCH 1/7] dm: use __GFP_HIGH instead PF_MEMALLOC KOSAKI Motohiro
2009-11-17 13:15 ` Alasdair G Kergon
2009-11-18 6:17 ` KOSAKI Motohiro
2009-11-17 7:17 ` [PATCH 2/7] mmc: Don't use PF_MEMALLOC KOSAKI Motohiro
2009-11-17 10:29 ` Alan Cox
2009-11-17 10:32 ` Minchan Kim
2009-11-17 10:38 ` Oliver Neukum
2009-11-17 11:58 ` KOSAKI Motohiro
2009-11-17 12:51 ` Minchan Kim
2009-11-17 20:47 ` Peter Zijlstra
2009-11-18 0:01 ` Minchan Kim
2009-11-18 9:56 ` Peter Zijlstra
2009-11-18 10:31 ` Minchan Kim
2009-11-18 10:54 ` Peter Zijlstra
2009-11-18 11:15 ` Minchan Kim
2009-11-17 7:18 ` [PATCH 3/7] mtd: " KOSAKI Motohiro
2009-11-17 7:19 ` [PATCH 4/7] nandsim: " KOSAKI Motohiro
2009-11-23 15:00 ` Artem Bityutskiy
2009-11-23 20:01 ` Adrian Hunter
2009-11-24 10:46 ` KOSAKI Motohiro
2009-11-24 11:56 ` Adrian Hunter
2009-11-25 0:42 ` KOSAKI Motohiro
2009-11-25 7:13 ` Adrian Hunter
2009-11-25 7:18 ` KOSAKI Motohiro
2009-11-17 7:21 ` [PATCH 5/7] Revert "Intel IOMMU: Avoid memory allocation failures in dma map api calls" KOSAKI Motohiro
2009-11-17 7:22 ` [PATCH 6/7] cifs: Don't use PF_MEMALLOC KOSAKI Motohiro
2009-11-17 7:32 ` [PATCH] Mark cifs mailing list as "moderated as non-subscribers" KOSAKI Motohiro
2009-11-17 12:47 ` [PATCH 6/7] cifs: Don't use PF_MEMALLOC Jeff Layton
2009-11-17 16:40 ` Steve French
2009-11-18 6:31 ` KOSAKI Motohiro
2009-11-17 7:23 ` [PATCH 7/7] xfs: " KOSAKI Motohiro
2009-11-17 22:11 ` Dave Chinner
2009-11-18 8:56 ` KOSAKI Motohiro
2009-11-18 22:16 ` Dave Chinner
2009-11-17 8:07 ` [PATCH 0/7] Kill PF_MEMALLOC abuse David Rientjes
2009-11-17 8:33 ` KOSAKI Motohiro [this message]
2009-11-17 8:36 ` David Rientjes
2009-11-17 20:56 ` Peter Zijlstra
2009-11-18 5:55 ` KOSAKI Motohiro
2009-11-17 10:15 ` Christoph Hellwig
2009-11-17 10:24 ` KOSAKI Motohiro
2009-11-17 10:27 ` Christoph Hellwig
2009-11-17 12:24 ` KOSAKI Motohiro
2009-11-17 12:47 ` Christoph Hellwig
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=20091117172802.3DF4.A69D9226@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
/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