On 31.01.23 14:41, David Howells wrote:
David Hildenbrand <david@xxxxxxxxxx> wrote:
percpu counters maybe - add them up at the point of viewing?
They are percpu, see my last email. But for every 108 changes (on
my system), they will do two atomic_long_adds(). So not very
useful for anything but low frequency modifications.
Can we just treat the whole acquired/released accounting as a debug mechanism
to detect missing releases and do it only for debug kernels?
The pcpu counter is an s8, so we have to flush on a regular basis and cannot
really defer it any longer ... but I'm curious if it would be of any help to
only have a single PINNED counter that goes into both directions (inc/dec on
pin/release), to reduce the flushing.
Of course, once we pin/release more than ~108 pages in one go or we switch
CPUs frequently it won't be that much of a help ...
What are the stats actually used for? Is it just debugging, or do we actually
have users for them (control groups spring to mind)?
As it's really just "how many pinning events" vs. "how many unpinning
events", I assume it's only for debugging.
For example, if you pin the same page twice it would not get accounted
as "a single page is pinned".
--
Thanks,
David / dhildenb
