[PATCH 0/19] get rid of superfluous __GFP_REPEAT

* [PATCH 0/19] get rid of superfluous __GFP_REPEAT
@ 2016-04-28 13:23 Michal Hocko
  2016-04-28 13:23 ` [PATCH 01/20] tree wide: get rid of __GFP_REPEAT for order-0 allocations part I Michal Hocko
                   ` (20 more replies)
  0 siblings, 21 replies; 40+ messages in thread
From: Michal Hocko @ 2016-04-28 13:23 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-mm, LKML, Andy Lutomirski, Benjamin Herrenschmidt,
	Catalin Marinas, Chen Liqin, Chris Metcalf, David S. Miller,
	Guan Xuetao, Heiko Carstens, Helge Deller, H. Peter Anvin,
	Ingo Molnar, James E.J. Bottomley, John Crispin, Lennox Wu,
	Ley Foon Tan, Martin Schwidefsky, Matt Fleming, Michal Hocko,
	Mikulas Patocka, Rich Felker, Russell King, Shaohua Li,
	Theodore Ts'o, Thomas Gleixner, Vineet Gupta, Will Deacon,
	Yoshinori Sato

Hi,
this is the thrid version of the patchset previously sent [1]. I have
basically only rebased it on top of next-20160428 tree and dropped
"crypto: get rid of superfluous __GFP_REPEAT" which went through crypto
tree. I have added two more md patches as I couldn't resist more alloc
related cleanups at that area.

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. One thought was to rename it to __GFP_BEST_EFFORT
which would behave consistently for all orders and guarantee that the
allocation would try as long as it seem feasible or fail eventually.
!costly request would then finally get a request context which neiter
fails too early (GFP_NORETRY) nor endlessly loops in the allocator for
ever (default behavior). Costly high order requests would keep the
current semantic.
We have discussed that at LSF/MM this year and another suggestion was
to introduce __GFP_TRYHARD instead which would be implicit for all
orders and users would opt out by ~__GFP_TRYHARD instead. I am not
sure which way is better right now but I plan to do the clean up first
before going further with semantic changes.

$ git grep __GFP_REPEAT next/master | wc -l
109
$ git grep __GFP_REPEAT | wc -l
35

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/1460372892-8157-1-git-send-email-mhocko@kernel.org

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

^ permalink raw reply	[flat|nested] 40+ messages in thread