From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: show_mem() for ia64 discontig takes a really long time on large systems.
Date: Thu, 30 Mar 2006 17:48:18 +0000 [thread overview]
Message-ID: <200603301747.k2UHlXg22156@unix-os.sc.intel.com> (raw)
In-Reply-To: <20060328184315.GA8162@lnx-holt.americas.sgi.com>
Jack Steiner wrote on Thursday, March 30, 2006 9:29 AM
> > Time is wasted trying to fill the TLB entry for the vmem_map. When it
> > fails, we show_mem() advances to the next page which repeats the sequence.
> > Jack had thrown out a couple suggestions. One was essentially what
> > you proposed below. The other was advance i to point the next page
> > of pfns. He frowned when saying the second, but I don't recall exactly
> > why he frowned.
>
> Advancing to the next page will be considerably faster but I wonder if
> it is fast enough.
>
> There are huge gaps in the virtual vmem_map. On shub2, for example, it
> is possible to have 180GB of unpopulated memory in the holes
> between memory banks on a node (mode=0).
>
> Assuming 56 bytes per struct_page, that gives:
>
> - 180GB = 11M pages
> - 38000 pages of struct_page entries
> - 38000 TLB faults to scan the holes in a node
>
> That is a lot of tlbmisses to scan a node. Multiply by 512 to
> get the number of faults to scan a full 512n system.
>
> My gut feeling is that is not good enough.
What about the earlier proposal of advancing at pmd and pud granule by
walking the page table? There it can walk at 32MB/64GB step.
- Ken
next prev parent reply other threads:[~2006-03-30 17:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-28 18:43 show_mem() for ia64 discontig takes a really long time on large systems Robin Holt
2006-03-28 19:16 ` show_mem() for ia64 discontig takes a really long time on Dave Hansen
2006-03-28 19:23 ` show_mem() for ia64 discontig takes a really long time on large systems Bob Picco
2006-03-28 19:34 ` show_mem() for ia64 discontig takes a really long time on Dave Hansen
2006-03-28 20:09 ` show_mem() for ia64 discontig takes a really long time on large systems Chen, Kenneth W
2006-03-28 20:56 ` Robin Holt
2006-03-28 21:00 ` Robin Holt
2006-03-29 0:18 ` show_mem() for ia64 discontig takes a really long time on large KAMEZAWA Hiroyuki
2006-03-30 17:29 ` show_mem() for ia64 discontig takes a really long time on large systems Jack Steiner
2006-03-30 17:48 ` Chen, Kenneth W [this message]
2006-03-30 18:18 ` Luck, Tony
2006-03-30 18:26 ` show_mem() for ia64 discontig takes a really long time on Dave Hansen
2006-03-30 18:28 ` show_mem() for ia64 discontig takes a really long time on large systems Luck, Tony
2006-03-30 18:34 ` show_mem() for ia64 discontig takes a really long time on Dave Hansen
2006-03-30 19:24 ` show_mem() for ia64 discontig takes a really long time on large systems Chen, Kenneth W
2006-04-12 7:18 ` Robin Holt
2006-04-12 17:22 ` Chen, Kenneth W
2006-04-12 17:36 ` Bob Picco
2006-04-13 3:02 ` Robin Holt
2006-04-13 16:02 ` Robin Holt
2006-04-13 16:15 ` Bob Picco
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=200603301747.k2UHlXg22156@unix-os.sc.intel.com \
--to=kenneth.w.chen@intel.com \
--cc=linux-ia64@vger.kernel.org \
/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