On Tue, 04 Dec 2012 09:15:10 +0400
Pavel Emelyanov [off-list ref] wrote:

quoted

Two alternatives come to mind:

1)  Use /proc/pid/pagemap (Documentation/vm/pagemap.txt) in some
    fashion to determine which pages have been touched.

I thought about this. Unfortunately there's no free bits left in the pagemap
entry. What can we do about it (other than introducing the pagemap2 file)?

urgh, we were pretty careless in laying out the /proc/pid/pagemap
entries.

Probably the 55 bits for pfn/swap were excessive.

The page shift didn't need six bits!  Simply predividing the page shift
by 1k would have saved a few bits, and permitting expansion to a 1^63
byte page size is nuts.

Sigh.  I wonder how traumatic it would be to put the pagemap record on
a diet and make up some free space.


Anyway, do you actually need to add another bit?  /proc/pid/pagemap
gives you the pfn which can then be used to look up the page's flags in
/proc/pageflags.  You can add a "touched" flag to /proc/kpageflags? 
But that would require grabbing another bit in struct page.flags, I
assume.

And it would be very expensive.  An in-kernel loop which searches the
MM spitting out a string of touched-pages would be faster, but still
slow.

hm.

quoted

2)  At pagefault time, don't send an event: just mark the vma as
    "touched".  Then add a userspace interface to sweep the vma tree
    testing, clearing and reporting the touched flags.

Per-vma granularity is not enough. In OpenVZ we've observed Oracle touching
several pages in a hundred-megs anon mapping. Marking _part_ of the vma with
the "node write-faults" bit would help, but there's currently no APIs that
modifies vma and report some info back at the same time. Can you propose how
it could look like?

I don't see a need to report the info back at the same time?  You want
to *record* that information but only report it when someone does a
query?

Dunno.  One could add a radix-tree to the vma and store 32 or 64
per-page bits in each slots[] entry.  Worst case that would consume
approx one bit of kernel memory for each 4k of instantiated user pages
- an increase of 1/32768.  Not too bad.  Use the tagged-lookup facility
to efficiently query that bitmap at query-time.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>