[PATCH 0/19] get rid of superfluous __GFP_REPORT

* [PATCH 0/19] get rid of superfluous __GFP_REPORT
@ 2016-04-11 11:07 Michal Hocko
  2016-04-11 11:07 ` [PATCH 01/19] tree wide: get rid of __GFP_REPEAT for order-0 allocations part I Michal Hocko
                   ` (19 more replies)
  0 siblings, 20 replies; 41+ messages in thread
From: Michal Hocko @ 2016-04-11 11:07 UTC (permalink / raw)
  To: linux-mm
  Cc: Andrew Morton, LKML, Andy Lutomirski, Benjamin Herrenschmidt,
	Catalin Marinas, Chen Liqin, Chris Metcalf,
	Christian Borntraeger, Cornelia Huck, David S. Miller,
	Guan Xuetao, Helge Deller, Herbert Xu, H. Peter Anvin,
	Ingo Molnar, James E.J. Bottomley, John Crispin, Lennox Wu,
	Ley Foon Tan, 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 second version of the patchset previously sent [1]

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.

$ git grep __GFP_REPEAT next/master | wc -l
111
$ 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.

I am also interested whether this makes sense in general.

[1] http://lkml.kernel.org/r/1446740160-29094-1-git-send-email-mhocko@kernel.org

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