From: Stephen Hemminger <shemminger@vyatta.com>
To: Stephen Wilson <wilsons@start.ca>
Cc: linux-mm@kvack.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>,
David Rientjes <rientjes@google.com>,
Lee Schermerhorn <lee.schermerhorn@hp.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: regression in /proc/self/numa_maps with huge pages
Date: Wed, 19 Oct 2011 12:35:30 -0700 [thread overview]
Message-ID: <20111019123530.2e59b86c@nehalam.linuxnetplumber.net> (raw)
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? Looks like the desire to be generic
overstepped the desire to remain compatible.
This regression in kernel ABI was introduced by:
commit 29ea2f6982f1edc4302729116f2246dd7b45471d
Author: Stephen Wilson <wilsons@start.ca>
Date: Tue May 24 17:12:42 2011 -0700
mm: use walk_page_range() instead of custom page table walking code
Converting show_numa_map() to use the generic routine decouples the
function from mempolicy.c, allowing it to be moved out of the mm subsystem
and into fs/proc.
Also, include KSM pages in /proc/pid/numa_maps statistics. The pagewalk
logic implemented by check_pte_range() failed to account for such pages as
they were not applicable to the page migration case.
Signed-off-by: Stephen Wilson <wilsons@start.ca>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
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>
next reply other threads:[~2011-10-19 19:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 19:35 Stephen Hemminger [this message]
2011-10-19 20:10 ` Andrew Morton
2011-10-19 20:46 ` Stephen Hemminger
2011-10-19 20:52 ` David Rientjes
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=20111019123530.2e59b86c@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.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