All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>, Neil Brown <neilb@suse.de>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag
Date: Fri, 28 Jul 2017 10:52:49 +0100	[thread overview]
Message-ID: <20170728095249.n62p5nhqbekjd5yn@suse.de> (raw)
In-Reply-To: <20170728091904.14627-1-mhocko@kernel.org>

On Fri, Jul 28, 2017 at 11:19:04AM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> GFP_TEMPORARY has been introduced by e12ba74d8ff3 ("Group short-lived
> and reclaimable kernel allocations") along with __GFP_RECLAIMABLE. It's
> primary motivation was to allow users to tell that an allocation is
> short lived and so the allocator can try to place such allocations close
> together and prevent long term fragmentation. As much as this sounds
> like a reasonable semantic it becomes much less clear when to use the
> highlevel GFP_TEMPORARY allocation flag. How long is temporary? Can
> the context holding that memory sleep? Can it take locks? It seems
> there is no good answer for those questions.
> 
> The current implementation of GFP_TEMPORARY is basically
> GFP_KERNEL | __GFP_RECLAIMABLE which in itself is tricky because
> basically none of the existing caller provide a way to reclaim the
> allocated memory. So this is rather misleading and hard to evaluate for
> any benefits.
> 

At the time of the introduction, the users were all very short-lived
where short was for operations such as reading a proc file that discarded
buffers afterwards. However, it does seem to have misused over the last
few years and it was too easy to confuse "temporary" with "short lived"
and too easy to get confused about "how short lived is short lived?". On
that basis;

Acked-by: Mel Gorman <mgorman@suse.de>

-- 
Mel Gorman
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>, Neil Brown <neilb@suse.de>,
	Theodore Ts'o <tytso@mit.edu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag
Date: Fri, 28 Jul 2017 10:52:49 +0100	[thread overview]
Message-ID: <20170728095249.n62p5nhqbekjd5yn@suse.de> (raw)
In-Reply-To: <20170728091904.14627-1-mhocko@kernel.org>

On Fri, Jul 28, 2017 at 11:19:04AM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> GFP_TEMPORARY has been introduced by e12ba74d8ff3 ("Group short-lived
> and reclaimable kernel allocations") along with __GFP_RECLAIMABLE. It's
> primary motivation was to allow users to tell that an allocation is
> short lived and so the allocator can try to place such allocations close
> together and prevent long term fragmentation. As much as this sounds
> like a reasonable semantic it becomes much less clear when to use the
> highlevel GFP_TEMPORARY allocation flag. How long is temporary? Can
> the context holding that memory sleep? Can it take locks? It seems
> there is no good answer for those questions.
> 
> The current implementation of GFP_TEMPORARY is basically
> GFP_KERNEL | __GFP_RECLAIMABLE which in itself is tricky because
> basically none of the existing caller provide a way to reclaim the
> allocated memory. So this is rather misleading and hard to evaluate for
> any benefits.
> 

At the time of the introduction, the users were all very short-lived
where short was for operations such as reading a proc file that discarded
buffers afterwards. However, it does seem to have misused over the last
few years and it was too easy to confuse "temporary" with "short lived"
and too easy to get confused about "how short lived is short lived?". On
that basis;

Acked-by: Mel Gorman <mgorman@suse.de>

-- 
Mel Gorman
SUSE Labs

--
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>

  reply	other threads:[~2017-07-28  9:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28  9:19 [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag Michal Hocko
2017-07-28  9:19 ` Michal Hocko
2017-07-28  9:52 ` Mel Gorman [this message]
2017-07-28  9:52   ` Mel Gorman
2017-07-28 10:27   ` Michal Hocko
2017-07-28 10:27     ` Michal Hocko
2017-07-28 10:59     ` Mel Gorman
2017-07-28 10:59       ` Mel Gorman
2017-07-28 13:15 ` Vlastimil Babka
2017-07-28 13:15   ` Vlastimil Babka
2017-08-23 17:57 ` Pavel Machek
2017-08-23 17:57   ` Pavel Machek
2017-08-25  6:35   ` Michal Hocko
2017-08-25  6:35     ` Michal Hocko
2017-08-25  7:28     ` Pavel Machek
2017-08-25  8:04       ` Michal Hocko
2017-08-25  8:04         ` Michal Hocko
2017-08-25 21:39         ` Pavel Machek
2017-08-26  4:11           ` NeilBrown
2017-08-28 12:36             ` Michal Hocko
2017-08-28 12:36               ` Michal Hocko
2017-08-31  9:07               ` Pavel Machek
2017-08-31  9:29                 ` Mel Gorman
2017-08-31  9:29                   ` Mel Gorman
2017-08-28 12:35           ` Michal Hocko
2017-08-28 12:35             ` Michal Hocko
2017-08-31  9:10             ` Pavel Machek

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=20170728095249.n62p5nhqbekjd5yn@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=neilb@suse.de \
    --cc=tytso@mit.edu \
    --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.