From: "Luck, Tony" <tony.luck@intel.com>
To: Johannes Weiner <hannes@saeurebad.de>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, mingo@elte.hu, davem@davemloft.net,
hskinnemoen@atmel.com, cooloney@kernel.org, starvik@axis.com,
dhowells@redhat.com, ysato@users.sf.net, takata@linux-m32r.org,
geert@linux-m68k.org, ralf@linux-mips.org, kyle@parisc-linux.org,
paulus@samba.org, schwidefsky@de.ibm.com, lethal@linux-sh.org,
jdike@addtoit.com, miles@gnu.org, chris@zankel.net,
rmk@arm.linux.org.uk
Subject: RE: [RFC 00/21] Generic show_mem()
Date: Wed, 2 Apr 2008 14:53:45 -0700 [thread overview]
Message-ID: <1FE6DD409037234FAB833C420AA843ECF9DFC4@orsmsx424.amr.corp.intel.com> (raw)
In-Reply-To: <12071682142640-git-send-email-hannes@saeurebad.de>
> Tony, as far as I understand, ia64 jumps holes in the memory map with
> vmemmap_find_next_valid_pfn(). Any idea if and how this could be
> built into the generic show_mem() version?
Perhaps it might be worth looking at this when ia64 slims down to
just one memory model (using sparse virtual mem map). But I don't
think anyone is actively working on this. Right now we have two
very different show_mem() functions for the contig and discontig
cases.
This whole function sends shivers down my spine for a large
system though ... that inner loop looks at every single page
structure ... on a multi-terabyte machine that could run to
billions of cache misses. Hope the users aren't in a hurry
to see the answer ... or doing something painful like:
# watch -n 1 cat /proc/meminfo
-Tony
next prev parent reply other threads:[~2008-04-02 21:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-02 20:29 Johannes Weiner
2008-04-02 20:29 ` [RFC 01/22] Generic show_mem() implementation Johannes Weiner
2008-04-02 20:29 ` [RFC 02/22] x86: Use generic show_mem() Johannes Weiner
2008-04-02 20:29 ` [RFC 03/22] sparc64: " Johannes Weiner
2008-04-02 20:29 ` [RFC 04/22] avr32: " Johannes Weiner
2008-04-02 21:53 ` Luck, Tony [this message]
2008-04-02 22:02 ` [RFC 00/21] Generic show_mem() Johannes Weiner
2008-04-02 20:40 Johannes Weiner
2008-04-03 23:45 ` Johannes Weiner
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=1FE6DD409037234FAB833C420AA843ECF9DFC4@orsmsx424.amr.corp.intel.com \
--to=tony.luck@intel.com \
--cc=chris@zankel.net \
--cc=cooloney@kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=geert@linux-m68k.org \
--cc=hannes@saeurebad.de \
--cc=hskinnemoen@atmel.com \
--cc=jdike@addtoit.com \
--cc=kyle@parisc-linux.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miles@gnu.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=schwidefsky@de.ibm.com \
--cc=starvik@axis.com \
--cc=takata@linux-m32r.org \
--cc=ysato@users.sf.net \
/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