linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Linux-MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	NeilBrown <neilb@suse.de>,
	Thierry Reding <thierry.reding@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/7] mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves
Date: Wed, 11 Jan 2023 16:58:02 +0100	[thread overview]
Message-ID: <Y77cikPSHepZ/GQj@dhcp22.suse.cz> (raw)
In-Reply-To: <20230109151631.24923-7-mgorman@techsingularity.net>

On Mon 09-01-23 15:16:30, Mel Gorman wrote:
> Explicit GFP_ATOMIC allocations get flagged ALLOC_HARDER which is a bit
> vague. In preparation for removing __GFP_ATOMIC, give GFP_ATOMIC and
> other non-blocking allocation requests equal access to reserve.  Rename
> ALLOC_HARDER to ALLOC_NON_BLOCK to make it more clear what the flag
> means.

GFP_NOWAIT can be also used for opportunistic allocations which can and
should fail quickly if the memory is tight and more elaborate path
should be taken (e.g. try higher order allocation first but fall back to
smaller request if the memory is fragmented). Do we really want to give
those access to memory reserves as well?
-- 
Michal Hocko
SUSE Labs


  parent reply	other threads:[~2023-01-11 15:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 15:16 [PATCH 0/6 v2] Discard __GFP_ATOMIC Mel Gorman
2023-01-09 15:16 ` [PATCH 1/7] mm/page_alloc: Rename ALLOC_HIGH to ALLOC_MIN_RESERVE Mel Gorman
2023-01-11 15:18   ` Michal Hocko
2023-01-12  9:26     ` Mel Gorman
2023-01-09 15:16 ` [PATCH 2/7] mm/page_alloc: Treat RT tasks similar to __GFP_HIGH Mel Gorman
2023-01-11 15:27   ` Michal Hocko
2023-01-12  9:36     ` Mel Gorman
2023-01-12  9:47       ` Michal Hocko
2023-01-12 16:42         ` Mel Gorman
2023-01-13  9:04       ` David Laight
2023-01-13 11:09         ` Mel Gorman
2023-01-09 15:16 ` [PATCH 3/7] mm/page_alloc: Explicitly record high-order atomic allocations in alloc_flags Mel Gorman
2023-01-10 15:28   ` Vlastimil Babka
2023-01-11 15:36   ` Michal Hocko
2023-01-12  9:38     ` Mel Gorman
2023-01-09 15:16 ` [PATCH 4/7] mm/page_alloc: Explicitly define what alloc flags deplete min reserves Mel Gorman
2023-01-11 14:04   ` Vlastimil Babka
2023-01-11 15:37   ` Michal Hocko
2023-01-09 15:16 ` [PATCH 5/7] mm/page_alloc.c: Allow __GFP_NOFAIL requests deeper access to reserves Mel Gorman
2023-01-11 14:05   ` Vlastimil Babka
2023-01-11 15:46   ` Michal Hocko
2023-01-12  9:43     ` Mel Gorman
2023-01-09 15:16 ` [PATCH 6/7] mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations " Mel Gorman
2023-01-11 14:12   ` Vlastimil Babka
2023-01-11 15:58   ` Michal Hocko [this message]
2023-01-11 17:05     ` Mel Gorman
2023-01-12  8:11       ` Michal Hocko
2023-01-12  8:29         ` Michal Hocko
2023-01-12  9:24         ` Mel Gorman
2023-01-12  9:45           ` Michal Hocko
2023-01-14 22:10       ` NeilBrown
2023-01-16 10:29         ` Mel Gorman
2023-01-09 15:16 ` [PATCH 7/7] mm: discard __GFP_ATOMIC Mel Gorman
2023-01-12  8:12   ` Michal Hocko

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=Y77cikPSHepZ/GQj@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox