From: Michal Hocko <mhocko@kernel.org> To: <linux-mm@kvack.org> Cc: Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Catalin Marinas <catalin.marinas@arm.com>, Chen Liqin <liqin.linux@gmail.com>, Chris Metcalf <cmetcalf@mellanox.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Cornelia Huck <cornelia.huck@de.ibm.com>, "David S. Miller" <davem@davemloft.net>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Helge Deller <deller@gmx.de>, Herbert Xu <herbert@gondor.apana.org.au>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, "James E.J. Bottomley" <jejb@parisc-linux.org>, John Crispin <blogic@openwrt.org>, Lennox Wu <lennox.wu@gmail.com>, Ley Foon Tan <lftan@altera.com>, Matt Fleming <matt@codeblueprint.co.uk>, Michal Hocko <mhocko@suse.com>, Mikulas Patocka <mpatocka@redhat.com>, Rich Felker <dalias@libc.org>, Russell King <linux@arm.linux.org.uk>, Shaohua Li <shli@kernel.org>, "Theodore Ts'o" <tytso@mit.edu>, Thomas Gleixner <tglx@linutronix.de>, Vineet Gupta <vgupta@synopsys.com>, Will Deacon <will.deacon@arm.com>, Yoshinori Sato <ysato@users.sourceforge.jp> Subject: [PATCH 0/19] get rid of superfluous __GFP_REPORT Date: Mon, 11 Apr 2016 13:07:53 +0200 [thread overview] Message-ID: <1460372892-8157-1-git-send-email-mhocko@kernel.org> (raw) 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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: linux-mm@kvack.org Cc: Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@kernel.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Catalin Marinas <catalin.marinas@arm.com>, Chen Liqin <liqin.linux@gmail.com>, Chris Metcalf <cmetcalf@mellanox.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Cornelia Huck <cornelia.huck@de.ibm.com>, "David S. Miller" <davem@davemloft.net>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Helge Deller <deller@gmx.de>, Herbert Xu <herbert@gondor.apana.org.au>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, "James E.J. Bottomley" <jejb@parisc-linux.org>, John Crispin <blogic@openwrt.org>, Lennox Wu <lennox.wu@gmail.com>, Ley Foon Tan <lftan@altera.com>, Matt Fleming <matt@codeblueprint.co.uk>, Michal Hocko <mhocko@suse.com>, Mikulas Patocka <mpatocka@redhat.com>, Rich Felker <dalias@libc.org>, Russell King <linux@arm.linux.org.uk>, Shaohua Li <shli@kernel.org>, Theodore Ts'o <tytso@mit.edu>, Thomas Gleixner <tglx@linutronix.de>, Vineet Gupta <vgupta@synopsys.com>, Will Deacon <will.deacon@arm.com>, Yoshinori Sato <ysato@users.sourceforge.jp> Subject: [PATCH 0/19] get rid of superfluous __GFP_REPORT Date: Mon, 11 Apr 2016 13:07:53 +0200 [thread overview] Message-ID: <1460372892-8157-1-git-send-email-mhocko@kernel.org> (raw) 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 -- 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>
next reply other threads:[~2016-04-11 11:08 UTC|newest] Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-11 11:07 Michal Hocko [this message] 2016-04-11 11:07 ` [PATCH 0/19] get rid of superfluous __GFP_REPORT 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 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-14 19:56 ` David Rientjes 2016-04-14 19:56 ` David Rientjes 2016-04-15 7:44 ` Michal Hocko 2016-04-15 7:44 ` Michal Hocko 2016-04-15 7:44 ` Michal Hocko 2016-04-15 7:44 ` Michal Hocko 2016-04-11 11:07 ` [PATCH 02/19] x86: get rid of superfluous __GFP_REPEAT Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` [PATCH 03/19] x86/efi: " Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-12 15:53 ` Matt Fleming 2016-04-12 15:53 ` Matt Fleming 2016-04-11 11:07 ` [PATCH 04/19] arm: " Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` [PATCH 05/19] arm64: " Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 15:49 ` Will Deacon 2016-04-11 15:49 ` Will Deacon 2016-04-11 11:07 ` [PATCH 06/19] arc: " Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 11:07 ` Michal Hocko 2016-04-11 14:23 ` Vineet Gupta 2016-04-11 14:23 ` Vineet Gupta 2016-04-11 11:08 ` [PATCH 07/19] mips: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 08/19] nios2: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 09/19] parisc: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 10/19] score: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 11/19] powerpc: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 12/19] sparc: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 13/19] s390: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:28 ` Cornelia Huck 2016-04-11 11:28 ` Cornelia Huck 2016-04-11 11:28 ` Cornelia Huck 2016-04-11 12:47 ` Heiko Carstens 2016-04-11 12:47 ` Heiko Carstens 2016-04-11 11:08 ` [PATCH 14/19] sh: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 15/19] tile: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 16/19] unicore32: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 17/19] dm: get rid of superfluous gfp flags Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-15 12:29 ` Mikulas Patocka 2016-04-15 12:29 ` Mikulas Patocka 2016-04-15 13:08 ` Michal Hocko 2016-04-15 13:08 ` Michal Hocko 2016-04-15 18:41 ` Mikulas Patocka 2016-04-15 18:41 ` Mikulas Patocka 2016-04-16 20:31 ` Michal Hocko 2016-04-16 20:31 ` Michal Hocko 2016-04-22 12:47 ` Michal Hocko 2016-04-22 12:47 ` Michal Hocko 2016-04-26 17:20 ` Mikulas Patocka 2016-04-26 17:20 ` Mikulas Patocka 2016-04-27 8:35 ` Michal Hocko 2016-04-27 8:35 ` Michal Hocko 2016-04-27 8:35 ` Michal Hocko 2016-04-11 11:08 ` [PATCH 18/19] crypto: get rid of superfluous __GFP_REPEAT Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-14 6:27 ` Herbert Xu 2016-04-14 6:27 ` Herbert Xu 2016-04-14 7:02 ` Michal Hocko 2016-04-14 7:02 ` Michal Hocko 2016-04-14 8:16 ` Herbert Xu 2016-04-14 8:16 ` Herbert Xu 2016-04-14 8:51 ` [PATCH resend] " Michal Hocko 2016-04-14 8:51 ` Michal Hocko 2016-04-15 14:37 ` Herbert Xu 2016-04-15 14:37 ` Herbert Xu 2016-04-11 11:08 ` [PATCH 19/19] jbd2: " Michal Hocko 2016-04-11 11:08 ` Michal Hocko 2016-04-13 11:21 ` CC in git cover letter vs patches (was Re: [PATCH 0/19] get rid of superfluous __GFP_REPORT) Vineet Gupta 2016-04-13 11:21 ` Vineet Gupta 2016-04-13 11:21 ` Vineet Gupta 2016-04-13 13:33 ` Michal Hocko 2016-04-13 13:33 ` Michal Hocko
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=1460372892-8157-1-git-send-email-mhocko@kernel.org \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=benh@kernel.crashing.org \ --cc=blogic@openwrt.org \ --cc=borntraeger@de.ibm.com \ --cc=catalin.marinas@arm.com \ --cc=cmetcalf@mellanox.com \ --cc=cornelia.huck@de.ibm.com \ --cc=dalias@libc.org \ --cc=davem@davemloft.net \ --cc=deller@gmx.de \ --cc=gxt@mprc.pku.edu.cn \ --cc=herbert@gondor.apana.org.au \ --cc=hpa@zytor.com \ --cc=jejb@parisc-linux.org \ --cc=lennox.wu@gmail.com \ --cc=lftan@altera.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@arm.linux.org.uk \ --cc=liqin.linux@gmail.com \ --cc=luto@kernel.org \ --cc=matt@codeblueprint.co.uk \ --cc=mhocko@suse.com \ --cc=mingo@redhat.com \ --cc=mpatocka@redhat.com \ --cc=shli@kernel.org \ --cc=tglx@linutronix.de \ --cc=tytso@mit.edu \ --cc=vgupta@synopsys.com \ --cc=will.deacon@arm.com \ --cc=ysato@users.sourceforge.jp \ /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: linkBe 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.