From: "NeilBrown" <neilb@suse.de>
To: "Mel Gorman" <mgorman@techsingularity.net>
Cc: "Michal Hocko" <mhocko@suse.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Matthew Wilcox" <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Mel Gorman" <mgorman@suse.de>
Subject: Re: [PATCH] MM: discard __GFP_ATOMIC
Date: Fri, 19 Nov 2021 10:02:55 +1100 [thread overview]
Message-ID: <163727657594.13692.10357464624495712361@noble.neil.brown.name> (raw)
In-Reply-To: <20211118132753.GB3366@techsingularity.net>
On Fri, 19 Nov 2021, Mel Gorman wrote:
> On Thu, Nov 18, 2021 at 10:22:36AM +0100, Michal Hocko wrote:
> > [Cc Mel]
> >
>
> I think this patch should be ok. There are few direct users of __GFP_HIGH
> and some of them are borderline silly (e.g. mm/shmem.c specifying
> __GFP_HIGH|__GFP_NOMEMALLOC) while others just look questionable (
> drivers/md/raid10.c seems to assume __GFP_HIGH guarantees allocation
> success). Xen appears to be the worst abuser of __GFP_HIGH.
That __GFP_HIGH in raid10.c is passed to mempool_alloc(), so there is no
assumption that __GFP_HIGH will provide guarantees - the mempool does
that.
The comment - which I wrote 4 years ago and don't recall at all -
suggest it was purely about performance - get error handling out of the
way quickly. I doubt I could justify it if challenged...
Thanks,
NeilBrown
>
> --
> Mel Gorman
> SUSE Labs
>
>
next prev parent reply other threads:[~2021-11-18 23:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 4:39 [PATCH] MM: discard __GFP_ATOMIC NeilBrown
2021-11-17 13:18 ` Matthew Wilcox
2021-11-18 23:14 ` NeilBrown
2021-11-19 14:10 ` Matthew Wilcox
2021-11-20 10:51 ` NeilBrown
2021-11-22 16:54 ` Michal Hocko
2021-11-23 4:15 ` NeilBrown
2021-11-23 14:27 ` Michal Hocko
2021-11-18 9:22 ` Michal Hocko
2021-11-18 13:27 ` Mel Gorman
2021-11-18 23:02 ` NeilBrown [this message]
2021-11-22 16:43 ` Michal Hocko
2021-11-23 4:33 ` NeilBrown
2021-11-23 13:41 ` Michal Hocko
2022-04-30 18:30 ` Andrew Morton
2022-05-01 15:45 ` Michal Hocko
2022-09-06 7:35 ` Michal Hocko
2022-09-07 9:47 ` Mel Gorman
2022-10-17 2:38 ` Andrew Morton
2022-10-18 12:11 ` 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=163727657594.13692.10357464624495712361@noble.neil.brown.name \
--to=neilb@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=thierry.reding@gmail.com \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.