linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: rohitseth@google.com
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Andrew Morton <akpm@osdl.org>,
	Linux-mm@kvack.org, Linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: Adding a counter in vma to indicate the number of	physical pages backing it
Date: Tue, 13 Jun 2006 05:51:23 +0200	[thread overview]
Message-ID: <200606130551.23825.ak@suse.de> (raw)
In-Reply-To: <1150141369.9576.43.camel@galaxy.corp.google.com>

On Monday 12 June 2006 21:42, Rohit Seth wrote:
> On Mon, 2006-06-12 at 19:58 +0200, Andi Kleen wrote:
> > > It is just the price of those walks that makes smaps not an attractive
> > > solution for monitoring purposes.
> > 
> > It just shouldn't be used for that. It's a debugging hack and not really 
> > suitable for monitoring even with optimizations.
> > 
> > For monitoring if the current numa statistics are not good enough
> > you should probably propose new counters.
> 
> 
> numa stats are giving different data.  The proposed vma->nr_phys is the
> new counter that can provide a detailed information about physical mem
> usage at each virtual mem segment level.  

And for what do you need that?

It's somewhat useful to debug the NUMA tuning of your app (although
there are other ways to do that too) but do you
really need it for normal runtime monitoring? 


> I think having this 
> information in each vma keeps the impact (of adding new counter) to very
> low.
> 
> Second question is to advertize this value to user space.  Please let me
> know what suites the most among /proc, /sys or system call (or if there
> is any other mechanism then let me know) for a per process per segment
> related information.

I think we first need to identify the basic need.
Don't see why we even need per VMA information so far.

-Andi

--
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:[~2006-06-13  3:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-10  1:33 Rohit Seth
2006-06-10  2:42 ` Andrew Morton
2006-06-12 17:49   ` Rohit Seth
2006-06-10  7:35 ` Nick Piggin
2006-06-11 10:15   ` Jan Engelhardt
2006-06-12 17:36   ` Rohit Seth
2006-06-12 17:58     ` Andi Kleen
2006-06-12 19:42       ` Rohit Seth
2006-06-13  3:51         ` Andi Kleen [this message]
2006-06-13  4:27           ` Nick Piggin
2006-06-13 16:59           ` Rohit Seth
2006-06-13 17:28             ` Hugh Dickins
2006-06-13 18:09               ` Rohit Seth
2006-06-13 17:31             ` Andi Kleen
2006-06-11 16:09 ` Arjan van de Ven
2006-06-12 11:17   ` Andi Kleen
2006-06-12 12:49     ` Jan Engelhardt
2006-06-12 12:54       ` Andi Kleen
2006-06-12 16:43 ` Christoph Lameter
2006-06-13  5:53 [PATCH]: Adding a counter in vma to indicate the number of physical_pages_backing it Albert Cahalan
2006-06-13  5:56 ` Andi Kleen
2006-06-13 17:10   ` Rohit Seth
2006-06-13 17:18     ` Andi Kleen

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=200606130551.23825.ak@suse.de \
    --to=ak@suse.de \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=Linux-mm@kvack.org \
    --cc=akpm@osdl.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rohitseth@google.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