Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1719371 > unrolled thread

Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag Pavel Machek <pavel@ucw.cz> - 2017-08-24 18:10 +0200
    Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag Michal Hocko <mhocko@kernel.org> - 2017-08-25 08:40 +0200
      Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag Pavel Machek <pavel@ucw.cz> - 2017-08-25 09:30 +0200
        Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag Michal Hocko <mhocko@kernel.org> - 2017-08-25 10:10 +0200

#1719371 — Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag

Hi!

> 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.
> 
> I have checked some random users and none of them has added the flag
> with a specific justification. I suspect most of them just copied from
> other existing users and others just thought it might be a good idea
> to use without any measuring. This suggests that GFP_TEMPORARY just
> motivates for cargo cult usage without any reasoning.
> 
> I believe that our gfp flags are quite complex already and especially
> those with highlevel semantic should be clearly defined to prevent from
> confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and
> replace all existing users to simply use GFP_KERNEL. Please note that
> SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic
> and so they will be placed properly for memory fragmentation prevention.
> 
> I can see reasons we might want some gfp flag to reflect shorterm
> allocations but I propose starting from a clear semantic definition and
> only then add users with proper justification.

Dunno. < 1msec probably is temporary, 1 hour probably is not. If it causes
problems, can you just #define GFP_TEMPORARY GFP_KERNEL ? Treewide replace,
and then starting again goes not look attractive to me.

									Pavel

[toc] | [next] | [standalone]

#1719774

On Wed 23-08-17 19:57:09, Pavel Machek wrote:
> Hi!
> 
> > 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.
> > 
> > I have checked some random users and none of them has added the flag
> > with a specific justification. I suspect most of them just copied from
> > other existing users and others just thought it might be a good idea
> > to use without any measuring. This suggests that GFP_TEMPORARY just
> > motivates for cargo cult usage without any reasoning.
> > 
> > I believe that our gfp flags are quite complex already and especially
> > those with highlevel semantic should be clearly defined to prevent from
> > confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and
> > replace all existing users to simply use GFP_KERNEL. Please note that
> > SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic
> > and so they will be placed properly for memory fragmentation prevention.
> > 
> > I can see reasons we might want some gfp flag to reflect shorterm
> > allocations but I propose starting from a clear semantic definition and
> > only then add users with proper justification.
> 
> Dunno. < 1msec probably is temporary, 1 hour probably is not. If it causes
> problems, can you just #define GFP_TEMPORARY GFP_KERNEL ? Treewide replace,
> and then starting again goes not look attractive to me.

I do not think we want a highlevel GFP_TEMPORARY without any meaning.
This just supports spreading the flag usage without a clear semantic
and it will lead to even bigger mess. Once we can actually define what
the flag means we can also add its users based on that new semantic.
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1719797

[Multipart message — attachments visible in raw view] — view raw

On Fri 2017-08-25 08:35:46, Michal Hocko wrote:
> On Wed 23-08-17 19:57:09, Pavel Machek wrote:
> > Hi!
> > 
> > > 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.
> > > 
> > > I have checked some random users and none of them has added the flag
> > > with a specific justification. I suspect most of them just copied from
> > > other existing users and others just thought it might be a good idea
> > > to use without any measuring. This suggests that GFP_TEMPORARY just
> > > motivates for cargo cult usage without any reasoning.
> > > 
> > > I believe that our gfp flags are quite complex already and especially
> > > those with highlevel semantic should be clearly defined to prevent from
> > > confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and
> > > replace all existing users to simply use GFP_KERNEL. Please note that
> > > SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic
> > > and so they will be placed properly for memory fragmentation prevention.
> > > 
> > > I can see reasons we might want some gfp flag to reflect shorterm
> > > allocations but I propose starting from a clear semantic definition and
> > > only then add users with proper justification.
> > 
> > Dunno. < 1msec probably is temporary, 1 hour probably is not. If it causes
> > problems, can you just #define GFP_TEMPORARY GFP_KERNEL ? Treewide replace,
> > and then starting again goes not look attractive to me.
> 
> I do not think we want a highlevel GFP_TEMPORARY without any meaning.
> This just supports spreading the flag usage without a clear semantic
> and it will lead to even bigger mess. Once we can actually define what
> the flag means we can also add its users based on that new semantic.

It has real meaning.

You can define more exact meaning, and then adjust the usage. But
there's no need to do treewide replacement...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1719813

On Fri 25-08-17 09:28:19, Pavel Machek wrote:
> On Fri 2017-08-25 08:35:46, Michal Hocko wrote:
> > On Wed 23-08-17 19:57:09, Pavel Machek wrote:
[...]
> > > Dunno. < 1msec probably is temporary, 1 hour probably is not. If it causes
> > > problems, can you just #define GFP_TEMPORARY GFP_KERNEL ? Treewide replace,
> > > and then starting again goes not look attractive to me.
> > 
> > I do not think we want a highlevel GFP_TEMPORARY without any meaning.
> > This just supports spreading the flag usage without a clear semantic
> > and it will lead to even bigger mess. Once we can actually define what
> > the flag means we can also add its users based on that new semantic.
> 
> It has real meaning.

Which is?
 
> You can define more exact meaning, and then adjust the usage. But
> there's no need to do treewide replacement...

I have checked most of them and except for the initially added onces the
large portion where added without a good reasons or even break an
intuitive meaning by taking locks.

Seriously, if we need a short term semantic it should be clearly defined
first.

Is there any specific case why you think this patch is in a wrong
direction? E.g. a measurable regression?

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web