Messages in this thread |  | | Date | Thu, 5 Apr 2018 16:27:49 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH v1] kernel/trace:check the val against the available mem |
| |
On Thu 05-04-18 07:22:58, Matthew Wilcox wrote: > On Wed, Apr 04, 2018 at 09:12:52PM -0700, Joel Fernandes wrote: > > On Wed, Apr 4, 2018 at 7:58 PM, Matthew Wilcox <willy@infradead.org> wrote: > > > On Wed, Apr 04, 2018 at 11:47:30AM -0400, Steven Rostedt wrote: > > >> I originally was going to remove the RETRY_MAYFAIL, but adding this > > >> check (at the end of the loop though) appears to have OOM consistently > > >> kill this task. > > >> > > >> I still like to keep RETRY_MAYFAIL, because it wont trigger OOM if > > >> nothing comes in and tries to do an allocation, but instead will fail > > >> nicely with -ENOMEM. > > > > > > I still don't get why you want RETRY_MAYFAIL. You know that tries > > > *harder* to allocate memory than plain GFP_KERNEL does, right? And > > > that seems like the exact opposite of what you want. > > > > No. We do want it to try harder but not if its already setup for failure. > > I understand you don't want GFP_NORETRY. But why is it more important for > this allocation to succeed than other normal GFP_KERNEL allocations?
I guess they simply want a failure rather than OOM even when they can shoot themselves into head by using oom_origin. It is still quite ugly to see OOM report...
-- Michal Hocko SUSE Labs
|  |