On Thu, 15 Feb 2024 15:33:30 -0500 Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > Well, I think without __GFP_NOWARN it will cause a warning and thus > > recursion into __show_mem(), potentially infinite? Which is of course > > trivial to fix, but I'd myself rather sacrifice a bit of memory to get > > this potentially very useful output, if I enabled the profiling. The > > necessary memory overhead of page_ext and slabobj_ext makes the > > printing buffer overhead negligible in comparison? > > __GFP_NOWARN is a good point, we should have that. > > But - and correct me if I'm wrong here - doesn't an OOM kick in well > before GFP_ATOMIC 4k allocations are failing? I'd expect the system to > be well and truly hosed at that point. > > If we want this report to be 100% reliable, then yes the preallocated > buffer makes sense - but I don't think 100% makes sense here; I think we > can accept ~99% and give back that 4k. I just compiled v6.8-rc4 vanilla (with a fedora localmodconfig build) and saved it off (vmlinux.orig), then I compiled with the following: Applied the patches but did not enable anything: vmlinux.memtag-off Enabled MEM_ALLOC_PROFILING: vmlinux.memtag Enabled MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT: vmlinux.memtag-default-on Enabled MEM_ALLOC_PROFILING_DEBUG: vmlinux.memtag-debug And here's what I got: text data bss dec hex filename 29161847 18352730 5619716 53134293 32ac3d5 vmlinux.orig 29162286 18382638 5595140 53140064 32ada60 vmlinux.memtag-off (+5771) 29230868 18887662 5275652 53394182 32ebb06 vmlinux.memtag (+259889) 29230746 18887662 5275652 53394060 32eba8c vmlinux.memtag-default-on (+259767) dropped? 29276214 18946374 5177348 53399936 32ed180 vmlinux.memtag-debug (+265643) Just adding the patches increases the size by 5k. But the rest shows an increase of 259k, and you are worried about 4k (and possibly less?)??? -- Steve
