linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Pavel Emelyanov <xemul@parallels.com>,
	Hugh Dickins <hughd@google.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Michal Hocko <mhocko@suse.cz>, Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Linux MM <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [RFC PATCH 0/2] mm: Add ability to monitor task's memory changes
Date: Tue, 04 Dec 2012 18:17:08 -0600	[thread overview]
Message-ID: <1354666628.6733.227.camel@calx> (raw)
In-Reply-To: <20121204152121.e5c33938.akpm@linux-foundation.org>

On Tue, 2012-12-04 at 15:21 -0800, Andrew Morton wrote:
> On Tue, 04 Dec 2012 09:15:10 +0400
> Pavel Emelyanov <xemul@parallels.com> 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@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>

  reply	other threads:[~2012-12-05  0:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-30 17:55 [RFC PATCH 0/2] mm: Add ability to monitor task's memory changes Pavel Emelyanov
2012-11-30 17:55 ` [PATCH 1/2] mm: Mark VMA with VM_TRACE bit Pavel Emelyanov
2012-11-30 17:55 ` [PATCH 2/2] mm: Generate events when tasks change their memory Pavel Emelyanov
2012-12-03 23:42   ` Xiao Guangrong
2012-12-04  5:04     ` Pavel Emelyanov
2012-12-03  8:36 ` [RFC PATCH 0/2] mm: Add ability to monitor task's memory changes Glauber Costa
2012-12-03 20:16   ` Marcelo Tosatti
2012-12-04  7:39     ` Glauber Costa
2012-12-03 22:43 ` Andrew Morton
2012-12-04  5:15   ` Pavel Emelyanov
2012-12-04 23:21     ` Andrew Morton
2012-12-05  0:17       ` Matt Mackall [this message]
2012-12-05  0:24         ` Andrew Morton
2012-12-05  0:38           ` Matt Mackall
2012-12-05  9:53             ` Pavel Emelyanov
2012-12-05 22:06               ` Andrew Morton
2012-12-06  6:32                 ` Pavel Emelyanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1354666628.6733.227.camel@calx \
    --to=mpm@selenic.com \
    --cc=akpm@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=riel@redhat.com \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).