On 11/23/20 4:10 PM, Charan Teja Kalla wrote:
Thanks Michal!
On 11/23/2020 7:43 PM, Michal Hocko wrote:
On Mon 23-11-20 19:33:16, Charan Teja Reddy wrote:
When the pages are failed to get isolate or migrate, the page owner
information along with page info is dumped. If there are continuous
failures in migration(say page is pinned) or isolation, the log buffer
is simply getting flooded with the page owner information. As most of
the times page info is sufficient to know the causes for failures of
migration or isolation, place the page owner information under DEBUG_VM.
I do not see why this path is any different from others that call
dump_page. Page owner can add a very valuable information to debug
the underlying reasons for failures here. It is an opt-in debugging
feature which needs to be enabled explicitly. So I would argue users
are ready to accept a lot of data in the kernel log.
Just thinking how frequently failures can happen in those paths. In the
memory hotplug path, we can flood the page owner logs just by making one
page pinned. Say If it is anonymous page, the page owner information
So you say it's flooded when page_owner info is included, but not
flooded when only the rest of __dump_page() is printed? (which is also
not just one or two lines). That has to be very specific rate of failures.
Anyway I don't like the solution with arbitrary config option. To
prevent flooding we generally have ratelimiting, how about that?
Also agreed with Michal that page_owner is explicitly enabled debugging
option and if you use it in production, that's rather surprising to me,
and possibly more rare than DEBUG_VM, which IIRC Fedora kernels use.
