Re: vmtrace

["Scott F. H. Kaplan" <sfkaplan@cs.amherst.edu>]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

Hello Marcelo (and everyone on linux-mm),

On Wed, Sep 28, 2005 at 04:29:29PM -0300, Marcelo Tosatti wrote:

> We've been talking on IRC on how to generate reference traces for
> memory accesses, and a suggestion came up to periodically unmap all
> present pte's of a given process.

There are known accuracy limitations to this approach.  Most
importantly, during any phase change, if you don't unmap the present
PTE's often enough, you will introduce substantial error into any
simulations that use these traces.

> Note: The patch lacks "pte_disable"/"pte_enable" macro pair (those
> are supposed to operate on a free bit in the flags field of the page
> table which was defined as PTE_DISABLE) and "pte_presprotect" macro
> to disable the PTE_PRESENT bit. I had that written down but _I LOST
> MY LAPTOP_ with the complete patch inside :(

Ugh!  Sorry to hear that.  I do have my own PTE_DISABLE and PTE_ENABLE
in the kVMTrace patch that should be easy to extract.  Note, though,
that I found it necessary to use two bits -- one to denote a PTE
disabled by the trace-gathering mechanism, and one to denote a PTE
disabled by a user-level mprotect() request.  This differentiation is
necessary for correctness.

> Scott, do you have any plans to port your work to v2.6? Relayfs
> (present in recent v2.6 kernels) implements a mechanism to send data
> to userspace which is very convenient.

If by ``plans'' you mean ``desire'', then yes; if you mean ``an
organized timeline'', then no.  I must say, though, that the relayfs
sounds as though it will make the porting much easier, allowing me to
strip out the ad-hoc in-kernel logging mechanism that I use in the
2.4-based kVMTrace.

I'm using kVMTrace actively to drive some research.  If there's a
demand for a 2.6-based version of it, then I'm certainly interested in
porting it forward, *especially* if there's anyone out there who would
like to help me along! :-) Most of the hard work isn't in the kernel
-- that portion is simple.  The bulk of the work is in the
post-processing utility that reconstructs the state of every task in
order to attribute each reference to the task that performed it and to
identify all uses of shared memory.  I am hopeful, though, that the
changes from 2.4 to 2.6 won't be all that onerous in this respect.

Scott

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]