linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	Stephen Wilson <wilsons@start.ca>,
	linux-mm@kvack.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Hugh Dickins <hughd@google.com>,
	Lee Schermerhorn <lee.schermerhorn@hp.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>
Subject: Re: regression in /proc/self/numa_maps with huge pages
Date: Wed, 19 Oct 2011 13:52:19 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1110191345290.5687@chino.kir.corp.google.com> (raw)
In-Reply-To: <20111019131007.e0d1c561.akpm@linux-foundation.org>

On Wed, 19 Oct 2011, Andrew Morton wrote:

> > We are working on an application that uses a library that uses
> > both huge pages and parses numa_maps.  This application is no longer
> > able to identify the socket id correctly for huge pages because the
> > that 'huge' is no longer part of /proc/self/numa_maps.
> > 
> > Basically, application sets up huge page mmaps, then reads /proc/self/numa_maps
> > and skips all entries without the string " huge ".  Then it looks for address
> > and socket info.
> > 
> > Why was this information dropped?
> 
> Mistake?
> 
> > Looks like the desire to be generic
> > overstepped the desire to remain compatible.
> 
> Or it was a mistake.
> 
> This?
> 
> --- a/fs/proc/task_mmu.c~a
> +++ a/fs/proc/task_mmu.c
> @@ -1009,6 +1009,9 @@ static int show_numa_map(struct seq_file
>  		seq_printf(m, " stack");
>  	}
>  
> +	if (is_vm_hugetlb_page(vma))
> +		seq_printf(m, " huge");
> +
>  	walk_page_range(vma->vm_start, vma->vm_end, &walk);
>  
>  	if (!md->pages)

Hmm, Dave Hansen (cc'd) was working on a patch that would add a pagesize= 
field to /proc/pid/numa_maps because there's now a discrepency in what is 
labeled "huge."  Hugetlbfs pages, for which "huge" would now be shown 
again for the patch above, always have their page counts shown in their 
appropriate hugepage size (2M, 1G for x86, others for other archs) which 
is ambiguous with just "huge" shown.  THP page counts, on the other hand, 
are always shown in PAGE_SIZE pages.

So adding "huge" back is ambiguous in terms of hugetlbfs size and doesn't 
represent THP hugepages.  No objection to the patch if it's strictly for 
numa_maps compatibility starting from 3.0, but we need to extend the 
output with a pagesize= type field unless we want to require users to use 
/proc/pid/smaps anytime they want to parse the page counts emitted by 
numa_maps.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2011-10-19 20:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19 19:35 Stephen Hemminger
2011-10-19 20:10 ` Andrew Morton
2011-10-19 20:46   ` Stephen Hemminger
2011-10-19 20:52   ` David Rientjes [this message]

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=alpine.DEB.2.00.1110191345290.5687@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-mm@kvack.org \
    --cc=shemminger@vyatta.com \
    --cc=wilsons@start.ca \
    /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