All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	minchan.kim@gmail.com
Subject: Re: [RFC mm][PATCH 2/5] percpu cached mm counter
Date: Thu, 10 Dec 2009 18:38:19 +0100	[thread overview]
Message-ID: <20091210173819.GA5256@elte.hu> (raw)
In-Reply-To: <alpine.DEB.2.00.0912101134220.5481@router.home>


* Christoph Lameter <cl@linux-foundation.org> wrote:

> On Thu, 10 Dec 2009, Ingo Molnar wrote:
> 
> >
> > No, i'm not suggesting that - i'm just suggesting that right now MM
> > stats are not very well suited to be exposed via perf. If we wanted to
> > measure/sample the information in /proc/<pid>/statm it just wouldnt be
> > possible. We have a few events like pagefaults and a few tracepoints as
> > well - but more would be possible IMO.
> 
> vital MM stats are exposed via /proc/<pid> interfaces. Performance 
> monitoring is something optional MM VM stats are used for VM decision 
> on memory and process handling.

You list a few facts here but what is your point?

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	minchan.kim@gmail.com
Subject: Re: [RFC mm][PATCH 2/5] percpu cached mm counter
Date: Thu, 10 Dec 2009 18:38:19 +0100	[thread overview]
Message-ID: <20091210173819.GA5256@elte.hu> (raw)
In-Reply-To: <alpine.DEB.2.00.0912101134220.5481@router.home>


* Christoph Lameter <cl@linux-foundation.org> wrote:

> On Thu, 10 Dec 2009, Ingo Molnar wrote:
> 
> >
> > No, i'm not suggesting that - i'm just suggesting that right now MM
> > stats are not very well suited to be exposed via perf. If we wanted to
> > measure/sample the information in /proc/<pid>/statm it just wouldnt be
> > possible. We have a few events like pagefaults and a few tracepoints as
> > well - but more would be possible IMO.
> 
> vital MM stats are exposed via /proc/<pid> interfaces. Performance 
> monitoring is something optional MM VM stats are used for VM decision 
> on memory and process handling.

You list a few facts here but what is your point?

	Ingo

--
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:[~2009-12-10 17:38 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10  7:31 [RFC mm][PATCH 0/5] per mm counter updates KAMEZAWA Hiroyuki
2009-12-10  7:31 ` KAMEZAWA Hiroyuki
2009-12-10  7:33 ` [RFC mm][PATCH 1/5] mm counter cleanup KAMEZAWA Hiroyuki
2009-12-10  7:33   ` KAMEZAWA Hiroyuki
2009-12-10 17:30   ` Christoph Lameter
2009-12-10 17:30     ` Christoph Lameter
2009-12-10 23:42     ` KAMEZAWA Hiroyuki
2009-12-10 23:42       ` KAMEZAWA Hiroyuki
2009-12-11  0:07     ` Minchan Kim
2009-12-11  0:07       ` Minchan Kim
2009-12-10  7:34 ` [RFC mm][PATCH 2/5] percpu cached mm counter KAMEZAWA Hiroyuki
2009-12-10  7:34   ` KAMEZAWA Hiroyuki
2009-12-10  7:54   ` Ingo Molnar
2009-12-10  7:54     ` Ingo Molnar
2009-12-10  8:20     ` KAMEZAWA Hiroyuki
2009-12-10  8:20       ` KAMEZAWA Hiroyuki
2009-12-10  8:33       ` Ingo Molnar
2009-12-10  8:33         ` Ingo Molnar
2009-12-10  8:42         ` KAMEZAWA Hiroyuki
2009-12-10  8:42           ` KAMEZAWA Hiroyuki
2009-12-10 17:35         ` Christoph Lameter
2009-12-10 17:35           ` Christoph Lameter
2009-12-10 17:38           ` Ingo Molnar [this message]
2009-12-10 17:38             ` Ingo Molnar
2009-12-10 18:04             ` Christoph Lameter
2009-12-10 18:04               ` Christoph Lameter
2009-12-10 18:54               ` Ingo Molnar
2009-12-10 18:54                 ` Ingo Molnar
2009-12-11  0:11                 ` KAMEZAWA Hiroyuki
2009-12-11  0:11                   ` KAMEZAWA Hiroyuki
2009-12-10 17:34     ` Christoph Lameter
2009-12-10 17:34       ` Christoph Lameter
2009-12-10 17:51   ` Christoph Lameter
2009-12-10 17:51     ` Christoph Lameter
2009-12-11  0:30     ` KAMEZAWA Hiroyuki
2009-12-11  0:30       ` KAMEZAWA Hiroyuki
2009-12-11  0:40   ` Minchan Kim
2009-12-11  0:40     ` Minchan Kim
2009-12-11  0:51     ` KAMEZAWA Hiroyuki
2009-12-11  0:51       ` KAMEZAWA Hiroyuki
2009-12-11  1:25       ` Minchan Kim
2009-12-11  1:25         ` Minchan Kim
2009-12-11  1:26         ` KAMEZAWA Hiroyuki
2009-12-11  1:26           ` KAMEZAWA Hiroyuki
2009-12-10  7:59 ` [RFC mm][PATCH 3/5] counting swap ents per mm KAMEZAWA Hiroyuki
2009-12-10  7:59   ` KAMEZAWA Hiroyuki
2009-12-10 17:55   ` Christoph Lameter
2009-12-10 17:55     ` Christoph Lameter
2009-12-11  0:33     ` KAMEZAWA Hiroyuki
2009-12-11  0:33       ` KAMEZAWA Hiroyuki
2009-12-11  1:07   ` Minchan Kim
2009-12-11  1:07     ` Minchan Kim
2009-12-10  8:00 ` [RFC mm][PATCH 4/5] add a lowmem check function KAMEZAWA Hiroyuki
2009-12-10  8:00   ` KAMEZAWA Hiroyuki
2009-12-10 17:59   ` Christoph Lameter
2009-12-10 17:59     ` Christoph Lameter
2009-12-11  0:39     ` KAMEZAWA Hiroyuki
2009-12-11  0:39       ` KAMEZAWA Hiroyuki
2009-12-11 13:35       ` Christoph Lameter
2009-12-11 13:35         ` Christoph Lameter
2009-12-11  1:09   ` Minchan Kim
2009-12-11  1:09     ` Minchan Kim
2009-12-10  8:01 ` [RFC mm][PATCH 5/5] counting lowmem rss per mm KAMEZAWA Hiroyuki
2009-12-10  8:01   ` KAMEZAWA Hiroyuki
2009-12-11  1:12   ` Minchan Kim
2009-12-11  1:12     ` Minchan Kim
2009-12-10  8:03 ` [RFC mm][PATCH 0/5] per mm counter updates KAMEZAWA Hiroyuki
2009-12-10  8:03   ` KAMEZAWA Hiroyuki

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=20091210173819.GA5256@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.