Tagscan module walks physical pages and analyses tag presence (DO NOT MERGE)

[rwatson]

This kernel module walks the physical page list and analyses tagged values found in the page to report various memory and tag stats, as well as proportions of pages with capabilities, object type owning those capabilities, estimated memory overhead, and so on.

This is experimental work and is not currently a merge candidate. Pushed as a branch for sharing and discussion purposes.

[markjdb]

Most of these flags are meaningless if the page is free, they might be left set (flags are initialized at page allocation time) and so incorrectly contribute to totals.

That is, I suspect we should verify that m->order == VM_NFREEORDER first to ensure that the page isn't enqueued in the physical memory allocator.

[rwatson]

On the whole the stats we care about are those associated with pages that had an object, and our various overhead / density calculations are based only on those pages. That said, I think we do care about free pages that have tags in them, for some purposes, and we should report this in a more clear way.

What is the authoritative check for m “free” that we should use?

[markjdb]

That's fair. My comment really only meant to refer to all of these m->[ao]flags checks.

The authoritative check is m->order < VM_NFREEORDER. If this condition is true, the page is free, else we must have m->order == VM_NFREEORDER.

In fact, the above isn't quite authoritative, it doesn't count pages that are free in the per-CPU caches. However, the size of those caches is bounded to something like 1% of RAM, and there's no easy way to check for them. So, I think the above check of m->order is likely "good enough".