On Thu, 15 Feb 2024 15:33:30 -0500
Kent Overstreet [off-list ref] wrote:
quoted
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