From: Steven Rostedt <rostedt@goodmis.org> To: Michal Hocko <mhocko@kernel.org> Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>, Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org, Andrew Morton <akpm@linux-foundation.org>, Joel Fernandes <joelaf@google.com>, linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz> Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem Date: Tue, 3 Apr 2018 18:56:27 -0400 [thread overview] Message-ID: <20180403185627.6bf9ea9b@gandalf.local.home> (raw) In-Reply-To: <20180403161119.GE5501@dhcp22.suse.cz> On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko <mhocko@kernel.org> wrote: > You can do so, of course. In fact it would have some advantages over > single pages because you would fragment the memory less but this is not > a reliable prevention from OOM killing and the complete memory > depletion if you allow arbitrary trace buffer sizes. You are right that this doesn't prevent OOM killing. I tried various methods, and the only thing that currently "works" the way I'm happy with, is this original patch. >From your earlier email: > Except that it doesn't work. si_mem_available is not really suitable for > any allocation estimations. Its only purpose is to provide a very rough > estimation for userspace. Any other use is basically abuse. The > situation can change really quickly. Really it is really hard to be > clever here with the volatility the memory allocations can cause. Now can you please explain to me why si_mem_available is not suitable for my purpose. If it's wrong and states there is less memory than actually exists, we simply fail to increase the buffer. If it is wrong and states that there is more memory than actually exists, then we do nothing different than what we do today, and trigger an OOM. But for the ring buffer use case, it is "good enough". Can you please explain to me what issues you see that can happen if we apply this patch? -- Steve
WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt@goodmis.org> To: Michal Hocko <mhocko@kernel.org> Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>, Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org, Andrew Morton <akpm@linux-foundation.org>, Joel Fernandes <joelaf@google.com>, linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz> Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem Date: Tue, 3 Apr 2018 18:56:27 -0400 [thread overview] Message-ID: <20180403185627.6bf9ea9b@gandalf.local.home> (raw) In-Reply-To: <20180403161119.GE5501@dhcp22.suse.cz> On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko <mhocko@kernel.org> wrote: > You can do so, of course. In fact it would have some advantages over > single pages because you would fragment the memory less but this is not > a reliable prevention from OOM killing and the complete memory > depletion if you allow arbitrary trace buffer sizes. You are right that this doesn't prevent OOM killing. I tried various methods, and the only thing that currently "works" the way I'm happy with, is this original patch. From your earlier email: > Except that it doesn't work. si_mem_available is not really suitable for > any allocation estimations. Its only purpose is to provide a very rough > estimation for userspace. Any other use is basically abuse. The > situation can change really quickly. Really it is really hard to be > clever here with the volatility the memory allocations can cause. Now can you please explain to me why si_mem_available is not suitable for my purpose. If it's wrong and states there is less memory than actually exists, we simply fail to increase the buffer. If it is wrong and states that there is more memory than actually exists, then we do nothing different than what we do today, and trigger an OOM. But for the ring buffer use case, it is "good enough". Can you please explain to me what issues you see that can happen if we apply this patch? -- Steve
next prev parent reply other threads:[~2018-04-03 22:56 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-29 10:41 [PATCH v1] kernel/trace:check the val against the available mem 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 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 [this message] 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 2018-04-10 12:12 ` __GFP_LOW Дмитрий Леонтьев 2018-04-10 12:19 ` __GFP_LOW Matthew Wilcox 2018-04-10 12:19 ` __GFP_LOW Matthew Wilcox 2018-04-10 12:13 ` __GFP_LOW Дмитрий Леонтьев 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=20180403185627.6bf9ea9b@gandalf.local.home \ --to=rostedt@goodmis.org \ --cc=akpm@linux-foundation.org \ --cc=huangzhaoyang@gmail.com \ --cc=joelaf@google.com \ --cc=kernel-patch-test@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=mingo@kernel.org \ --cc=vbabka@suse.cz \ /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.