On 2/2/22 17:53, Waiman Long wrote:
On 2/1/22 10:28, Michal Hocko wrote:Pid could be used to correlate command instances (not perfectly if reuse
Cc VlastimilYes, it does add an extra 16 bytes per page overhead. The command name can
On Mon 31-01-22 17:03:28, Waiman Long wrote:
The page_owner information currently includes the pid of the callingI completely agree that pid is effectivelly useless (if not misleading)
task. That is useful as long as the task is still running. Otherwise,
the number is meaningless. To have more information about the allocating
tasks that had exited by the time the page_owner information is
retrieved, we need to store the command name of the task.
Add a new comm field into page_owner structure to store the command name
and display it when the page_owner information is retrieved.
but is comm really telling all that much to compensate for the
additional storage required for _each_ page in the system?
be useful if one want to find out which userspace command is responsible for
a problematic page allocation. Maybe we can remove pid from page_owner to
save 8 bytes as you also agree that this number is not that useful.
happens), but command name could have a higher chance to be useful. In my
experience the most useful were the stacktraces and gfp/order etc. anyway.
So I wouldn't be opposed replacing pid with comm. The mild size increase
should be acceptable, this is an opt-in feature for debugging sessions with
known tradeoff for memory and cpu overhead for the extra info.