On Tue, 2012-12-04 at 15:21 -0800, Andrew Morton wrote: > On Tue, 04 Dec 2012 09:15:10 +0400 > Pavel Emelyanov <xemul@xxxxxxxxxxxxx> wrote: > > > > > > Two alternatives come to mind: > > > > > > 1) Use /proc/pid/pagemap (Documentation/vm/pagemap.txt) in some > > > fashion to determine which pages have been touched. [momentarily coming out of kernel retirement for old man rant] This is a popular interface anti-pattern. You shouldn't use an interface that gives you huge amount of STATE to detect small amounts of CHANGE via manual differentiation. For example, you would be foolish to try to monitor an entire filesystem by stat()ing all files on the disk continually. It will be massively slow, only sort of work, and you'll miss changes sometimes. Instead, use inotify. Similarly, you shouldn't try to use an interface that gives you small amounts of CHANGE to get a large STATE via manual integration. For instance, you would be silly to try to get the current timestamp on a file by tracking every change to the filesystem since boot via inotify. It would be massively slow, only sort of work, and you'll get wrong answers sometimes. Instead, use stat(). Pagemap is unambiguously a STATE interface for making the kinds of measurements that such interfaces are good for. If you try to use it as a CHANGE interface, you may find sadness. I don't know what a good CHANGE interface here might look like, but tracepoints have been suggested in the past. If you want do something UNIXy, you could teach inotify to report write iovecs and then make it possible for /proc and /sys objects to report events through inotify. Lots of other neat possibilities would fall out of that, of course. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>