All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.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:29:18 +0000	[thread overview]
Message-ID: <20060330172918.GA27076@sgi.com> (raw)
In-Reply-To: <20060328184315.GA8162@lnx-holt.americas.sgi.com>

On Tue, Mar 28, 2006 at 02:56:40PM -0600, Robin Holt wrote:
> On Tue, Mar 28, 2006 at 11:16:19AM -0800, Dave Hansen wrote:
> > Could you explain a bit how this works on ia64?  I know about the
> > vmem_map.  Is the time spent on filling TLB entries when you hit a
> > 'struct page' that isn't backed by real memory?
> 
> 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. 



	


> 
> > Maybe something like this in your show_mem():
> > 
> >         for_each_pgdat(pgdat) {
> > 		...
> >                 for(i = 0; i < pgdat->node_spanned_pages; i++) {
> >                         struct page *page;
> >                         if (pfn_valid(pgdat->node_start_pfn + i))
> >                                 page = pfn_to_page(pgdat->node_start_pfn + i);
> >                         else
> > -				continue;
> > +				/* -1 to offset i++ */
> > +                              	pfn += hole_nr_pages(pfn) - 1;
> > 

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.



  parent reply	other threads:[~2006-03-30 17:29 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 ` Jack Steiner [this message]
2006-03-30 17:48 ` show_mem() for ia64 discontig takes a really long time on large systems Chen, Kenneth W
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=20060330172918.GA27076@sgi.com \
    --to=steiner@sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.