From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>, NeilBrown <neilb@suse.de>,
Thierry Reding <thierry.reding@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] mm: discard __GFP_ATOMIC
Date: Wed, 4 Jan 2023 12:04:36 +0000 [thread overview]
Message-ID: <20230104120436.nto7semvbrsvakjg@techsingularity.net> (raw)
In-Reply-To: <e7b8c312-5433-757d-fb9c-f2f993e4f999@suse.cz>
On Thu, Dec 08, 2022 at 07:17:48PM +0100, Vlastimil Babka wrote:
> > @@ -4081,13 +4081,14 @@ static inline bool zone_watermark_fast(struct zone *z, unsigned int order,
> > if (__zone_watermark_ok(z, order, mark, highest_zoneidx, alloc_flags,
> > free_pages))
> > return true;
> > +
> > /*
> > - * Ignore watermark boosting for GFP_ATOMIC order-0 allocations
> > + * Ignore watermark boosting for GFP_HIGH order-0 allocations
>
> There's no GFP_HIGH. We could either keep GFP_ATOMIC here if we want to talk
> about the high-level flag combo, or __GFP_HIGH if about the low-level
> detail. We're deep in the page allocator implementation so the latter would
> be OK.
>
Fixed
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2023-01-04 12:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 15:16 [RFC PATCH 0/6] Discard __GFP_ATOMIC Mel Gorman
2022-11-29 15:16 ` [PATCH 1/6] mm/page_alloc: Rename ALLOC_HIGH to ALLOC_MIN_RESERVE Mel Gorman
2022-12-08 16:12 ` Vlastimil Babka
2022-11-29 15:16 ` [PATCH 2/6] mm/page_alloc: Treat RT tasks similar to GFP_HIGH Mel Gorman
2022-12-08 16:16 ` Vlastimil Babka
2022-11-29 15:16 ` [PATCH 3/6] mm/page_alloc: Explicitly record high-order atomic allocations in alloc_flags Mel Gorman
2022-12-05 5:17 ` NeilBrown
2022-12-05 10:27 ` Mel Gorman
2022-12-08 16:51 ` Vlastimil Babka
2023-01-04 11:45 ` Mel Gorman
2022-11-29 15:16 ` [PATCH 4/6] mm/page_alloc: Explicitly define what alloc flags deplete min reserves Mel Gorman
2022-12-08 17:55 ` Vlastimil Babka
2023-01-04 12:02 ` Mel Gorman
2022-11-29 15:17 ` [PATCH 5/6] mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves Mel Gorman
2022-12-08 18:07 ` Vlastimil Babka
2023-01-04 12:03 ` Mel Gorman
2022-11-29 15:17 ` [PATCH 6/6] mm: discard __GFP_ATOMIC Mel Gorman
2022-12-08 18:17 ` Vlastimil Babka
2023-01-04 12:04 ` Mel Gorman [this message]
2023-01-05 13:49 ` Mike Rapoport
2023-01-05 21:53 ` NeilBrown
2023-01-06 9:35 ` Mel Gorman
2023-01-08 9:30 ` Mike Rapoport
-- strict thread matches above, loose matches on Subject: below --
2023-01-13 11:12 [PATCH 0/6 v3] Discard __GFP_ATOMIC Mel Gorman
2023-01-13 11:12 ` [PATCH 6/6] mm: discard __GFP_ATOMIC 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=20230104120436.nto7semvbrsvakjg@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=neilb@suse.de \
--cc=thierry.reding@gmail.com \
--cc=vbabka@suse.cz \
--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.