On Tue 20-02-24 12:18:49, Kent Overstreet wrote: > On Tue, Feb 20, 2024 at 05:23:29PM +0100, Michal Hocko wrote: > > On Mon 19-02-24 09:17:36, Suren Baghdasaryan wrote: > > [...] > > > For now I think with Vlastimil's __GFP_NOWARN suggestion the code > > > becomes safe and the only risk is to lose this report. If we get cases > > > with reports missing this data, we can easily change to reserved > > > memory. > > > > This is not just about missing part of the oom report. This is annoying > > but not earth shattering. Eating into very small reserves (that might be > > the only usable memory while the system is struggling in OOM situation) > > could cause functional problems that would be non trivial to test for. > > All that for debugging purposes is just lame. If you want to reuse the code > > for a different purpose then abstract it and allocate the buffer when you > > can afford that and use preallocated on when in OOM situation. > > > > We have always went extra mile to avoid potentially disruptive > > operations from the oom handling code and I do not see any good reason > > to diverge from that principle. > > Michal, I gave you the logic between dedicated reserves and system > reserves. Please stop repeating these vague what-ifs. Your argument makes little sense and it seems that it is impossible to explain that to you. I gave up on discussing this further with you. Consider NAK to any additional allocation from oom path unless you can give very _solid_ arguments this is absolutely necessary. "It's gona be fine and work most of the time" is not a solid argument. -- Michal Hocko SUSE Labs
