On Thu, Feb 15, 2024 at 3:56 PM Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > On Thu, Feb 15, 2024 at 06:27:29PM -0500, Steven Rostedt wrote: > > All this, and we are still worried about 4k for useful debugging :-/ I was planning to refactor this function to print one record at a time with a smaller buffer but after discussing with Kent, he has plans to reuse this function and having the report in one buffer is needed for that. > Every additional 4k still needs justification. And whether we burn a > reserve on this will have no observable effect on user output in > remotely normal situations; if this allocation ever fails, we've already > been in an OOM situation for awhile and we've already printed out this > report many times, with less memory pressure where the allocation would > have succeeded. I'm not sure this claim will always be true, specifically in the case of low-end devices with relatively low amounts of reserves and in the presence of a possible quick memory usage spike. We should also consider a case when panic_on_oom is set. All we get is one OOM report, so we get only one chance to capture this report. In any case, I don't yet have data to prove or disprove this claim but it will be interesting to test it with data from the field once the feature is deployed. 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.
