• Michal Hocko's avatar
    tree wide: get rid of __GFP_REPEAT for order-0 allocations part I · 32d6bd90
    Michal Hocko authored
    This is the third version of the patchset previously sent [1].  I have
    basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get
    rid of superfluous gfp flags" which went through dm tree.  I am sending
    it now because it is tree wide and chances for conflicts are reduced
    considerably when we want to target rc2.  I plan to send the next step
    and rename the flag and move to a better semantic later during this
    release cycle so we will have a new semantic ready for 4.8 merge window
    hopefully.
    
    Motivation:
    
    While working on something unrelated I've checked the current usage of
    __GFP_REPEAT in the tree.  It seems that a majority of the usage is and
    always has been bogus because __GFP_REPEAT has always been about costly
    high order allocations while we are using it for order-0 or very small
    orders very often.  It seems that a big pile of them is just a
    copy&paste when a code has been adopted from one arch to another.
    
    I think it makes some sense to get rid of them because they are just
    making the semantic more unclear.  Please note that GFP_REPEAT is
    documented as
    
    * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
    
    * _might_ fail.  This depends upon the particular VM implementation.
      while !costly requests have basically nofail semantic.  So one could
      reasonably expect that order-0 request with __GFP_REPEAT will not loop
      for ever.  This is not implemented right now though.
    
    I would like to move on with __GFP_REPEAT and define a better semantic
    for it.
    
      $ git grep __GFP_REPEAT origin/master | wc -l
      111
      $ git grep __GFP_REPEAT | wc -l
      36
    
    So we are down to the third after this patch series.  The remaining
    places really seem to be relying on __GFP_REPEAT due to large allocation
    requests.  This still needs some double checking which I will do later
    after all the simple ones are sorted out.
    
    I am touching a lot of arch specific code here and I hope I got it right
    but as a matter of fact I even didn't compile test for some archs as I
    do not have cross compiler for them.  Patches should be quite trivial to
    review for stupid compile mistakes though.  The tricky parts are usually
    hidden by macro definitions and thats where I would appreciate help from
    arch maintainers.
    
    [1] http://lkml.kernel.org/r/1461849846-27209-1-git-send-email-mhocko@kernel.org
    
    This patch (of 19):
    
    __GFP_REPEAT has a rather weak semantic but since it has been introduced
    around 2.6.12 it has been ignored for low order allocations.  Yet we
    have the full kernel tree with its usage for apparently order-0
    allocations.  This is really confusing because __GFP_REPEAT is
    explicitly documented to allow allocation failures which is a weaker
    semantic than the current order-0 has (basically nofail).
    
    Let's simply drop __GFP_REPEAT from those places.  This would allow to
    identify place which really need allocator to retry harder and formulate
    a more specific semantic for what the flag is supposed to do actually.
    
    Link: http://lkml.kernel.org/r/1464599699-30131-2-git-send-email-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Chen Liqin <liqin.linux@gmail.com>
    Cc: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
    Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: John Crispin <blogic@openwrt.org>
    Cc: Lennox Wu <lennox.wu@gmail.com>
    Cc: Ley Foon Tan <lftan@altera.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vineet Gupta <vgupta@synopsys.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    32d6bd90
Name
Last commit
Last update
..
boot Loading commit data...
configs Loading commit data...
include Loading commit data...
kernel Loading commit data...
lib Loading commit data...
mm Loading commit data...
oprofile Loading commit data...
platforms Loading commit data...
variants Loading commit data...
Kconfig Loading commit data...
Kconfig.debug Loading commit data...
Makefile Loading commit data...