kernel-side TODO

• Rename s/vmtrace/pgtrace/g
• Add versioning to "struct vm_trace_entry"!
• Use dcache cookies to transform inode+bdev into path (much easier to work with). At the moment, if files get deleted during the workload you're doomed, having no way to identify deleted inode numbers.
• Measure the impact of tracing (relayfs transmission at fault/find_get_page paths, capture daemon, pte unmapping).
• Timing: current kptecleaner unmap period is "HZ/2" (but HZ in practice since timer is jiffy clocked).
• Alternatives to timer:
  • "active PTE FIFO". This approach is used by S.F.Kaplan's "vmtrace" tool. Have a FIFO of mapped pte's. Clamp it a certain N size, not allowing more than N pte's to be mapped. Requires unmapping at fault path (touch pte flags, flush TLB).
• SMP support:
  • add CPUID field to entry
  • one kptecleaner thread per CPU. How to synchronize them?

userspace tools TODO

• Create a Makefile!
• vmtrace-split currently splits in per "inode+bdev" type only, should work on uid, pid, pwd, etc.

  From [http://nptltracetool.sourceforge.net/ NPTL trace tool]:

  • Trace cut : it is possible to work only on a part of the trace selected with a temporal or a numeric criteria.
  • Trace split : it is possible to split the trace into several files to get either one file per process or one file per thread.
  • Trace filtering : it is possible to filter the trace on various criteria such as event name, object name, kind of object or pid.
  • Log levels : it is possible to switch dynamically from a light trace to a richer or full trace.
  • Large volume of traces : the tool handles large trace files (more than 16 Go).
  • Continuous recording : the tool can keep only the last traces of the execution.
• vmtrace-split opens an unlimited amount of files, it should cap at 1024 open fd's and reuse those on demand.
• vmtrace-phase: recognize and classify common access patterns.
• Generate visual information such as avg.IRF histograms, address versus time graphs, etc, etc.