From: Matthew Wilcox <firstname.lastname@example.org> To: Steven Rostedt <email@example.com> Cc: Zhaoyang Huang <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, firstname.lastname@example.org, email@example.com, Andrew Morton <firstname.lastname@example.org>, Joel Fernandes <email@example.com>, Michal Hocko <firstname.lastname@example.org>, email@example.com, Vlastimil Babka <firstname.lastname@example.org>, Michal Hocko <email@example.com> Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem Date: Fri, 30 Mar 2018 13:53:56 -0700 Message-ID: <20180330205356.GA13332@bombadil.infradead.org> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, Mar 30, 2018 at 10:20:38AM -0400, Steven Rostedt wrote: > That said, it appears you are having issues that were caused by the > change by commit 848618857d2 ("tracing/ring_buffer: Try harder to > allocate"), where we replaced NORETRY with RETRY_MAYFAIL. The point of > NORETRY was to keep allocations of the tracing ring-buffer from causing > OOMs. But the RETRY was too strong in that case, because there were > those that wanted to allocate large ring buffers but it would fail due > to memory being used that could be reclaimed. Supposedly, RETRY_MAYFAIL > is to allocate with reclaim but still allow to fail, and isn't suppose > to trigger an OOM. From my own tests, this is obviously not the case. That's not exactly what the comment says in gfp.h: * __GFP_RETRY_MAYFAIL: The VM implementation will retry memory reclaim * procedures that have previously failed if there is some indication * that progress has been made else where. It can wait for other * tasks to attempt high level approaches to freeing memory such as * compaction (which removes fragmentation) and page-out. * There is still a definite limit to the number of retries, but it is * a larger limit than with __GFP_NORETRY. * Allocations with this flag may fail, but only when there is * genuinely little unused memory. While these allocations do not * directly trigger the OOM killer, their failure indicates that * the system is likely to need to use the OOM killer soon. The * caller must handle failure, but can reasonably do so by failing * a higher-level request, or completing it only in a much less * efficient manner. * If the allocation does fail, and the caller is in a position to * free some non-essential memory, doing so could benefit the system * as a whole. It seems to me that what you're asking for at the moment is lower-likelihood-of-failure-than-GFP_KERNEL, and it's not entirely clear to me why your allocation is so much more important than other allocations in the kernel. Also, the pattern you have is very close to that of vmalloc. You're allocating one page at a time to satisfy a multi-page request. In lieu of actually thinking about what you should do, I might recommend using the same GFP flags as vmalloc() which works out to GFP_KERNEL | __GFP_NOWARN (possibly | __GFP_HIGHMEM if you can tolerate having to kmap the pages when accessed from within the kernel).
next prev parent reply index Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-29 10:41 Zhaoyang Huang 2018-03-29 16:05 ` Steven Rostedt 2018-03-30 3:32 ` Zhaoyang Huang 2018-03-30 14:07 ` Steven Rostedt 2018-03-30 6:53 ` [Kernel-patch-test] " kbuild test robot 2018-03-30 6:54 ` kbuild test robot 2018-03-30 14:20 ` Steven Rostedt 2018-03-30 16:37 ` Joel Fernandes 2018-03-30 19:10 ` Steven Rostedt 2018-03-30 20:37 ` Joel Fernandes 2018-03-30 20:53 ` Matthew Wilcox [this message] 2018-03-30 21:30 ` Steven Rostedt 2018-03-30 21:42 ` Steven Rostedt 2018-03-30 23:38 ` Joel Fernandes 2018-03-31 1:41 ` Steven Rostedt 2018-03-31 2:18 ` Matthew Wilcox 2018-03-31 3:07 ` Steven Rostedt 2018-03-31 5:44 ` Joel Fernandes 2018-04-02 0:52 ` Zhaoyang Huang 2018-04-03 11:06 ` Michal Hocko 2018-04-03 11:51 ` Steven Rostedt 2018-04-03 12:16 ` Michal Hocko 2018-04-03 12:23 ` Steven Rostedt 2018-04-03 12:35 ` Michal Hocko 2018-04-03 13:32 ` Steven Rostedt 2018-04-03 13:56 ` Michal Hocko 2018-04-03 14:17 ` Steven Rostedt 2018-04-03 16:11 ` Michal Hocko 2018-04-03 16:59 ` Steven Rostedt 2018-04-03 22:56 ` Steven Rostedt 2018-04-04 6:20 ` Michal Hocko 2018-04-04 12:21 ` Joel Fernandes 2018-04-04 12:59 ` Steven Rostedt 2018-04-04 14:10 ` Michal Hocko 2018-04-04 14:25 ` Steven Rostedt 2018-04-04 14:42 ` Michal Hocko 2018-04-04 15:04 ` Steven Rostedt 2018-04-04 15:27 ` Michal Hocko 2018-04-04 15:38 ` Steven Rostedt 2018-04-04 2:58 ` Zhaoyang Huang 2018-04-04 6:23 ` Michal Hocko 2018-04-04 9:29 ` Zhaoyang Huang 2018-04-04 14:11 ` Steven Rostedt 2018-04-04 14:23 ` Michal Hocko 2018-04-04 14:31 ` Steven Rostedt 2018-04-04 14:47 ` Michal Hocko 2018-04-04 15:47 ` Steven Rostedt 2018-04-05 2:58 ` Matthew Wilcox 2018-04-05 4:12 ` Joel Fernandes 2018-04-05 14:22 ` Matthew Wilcox 2018-04-05 14:27 ` Michal Hocko 2018-04-05 14:34 ` Steven Rostedt 2018-04-05 15:13 ` Matthew Wilcox 2018-04-05 15:32 ` Michal Hocko 2018-04-05 16:15 ` Matthew Wilcox 2018-04-05 18:54 ` Michal Hocko 2018-04-05 20:15 ` __GFP_LOW Matthew Wilcox 2018-04-06 6:09 ` __GFP_LOW Michal Hocko 2018-04-08 4:27 ` __GFP_LOW Matthew Wilcox 2018-04-09 7:34 ` __GFP_LOW Michal Hocko 2018-04-09 15:51 ` __GFP_LOW Matthew Wilcox 2018-04-09 18:14 ` __GFP_LOW Michal Hocko [not found] ` <CA+JonM0HG9kWb6-0iyDQ8UMxTeR-f=+ZL89t5DvvDULDC8Sfyw@mail.gmail.com> 2018-04-10 12:19 ` __GFP_LOW Matthew Wilcox 2018-04-05 14:30 ` [PATCH v1] kernel/trace:check the val against the available mem Steven Rostedt
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=20180330205356.GA13332@bombadil.infradead.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git