LKML Archive on
help / color / mirror / Atom feed
From: Dave Hansen <>
To: KyongHo Cho <>
	Kukjin Kim <>,
	Ilho Lee <>,
	KeyYoung Park <>,
	KyongHo Cho <>,
	MinChan Kim <>,
	Andy Whitcroft <>
Subject: Re: [PATCH] ARM: mm: Regarding section when dealing with meminfo
Date: Thu, 20 Jan 2011 10:04:13 -0800	[thread overview]
Message-ID: <1295546653.9039.680.camel@nimitz> (raw)
In-Reply-To: <>

On Fri, 2011-01-21 at 02:38 +0900, KyongHo Cho wrote:
> Actually, as long as a bank in meminfo only resides in a pgdat, no
> problem happens
> because there is no restriction of size of area in a pgdat.
> That's why I just considered about sparsemem.

Ahh, so "banks" are always underneath a single pgdat, and a "bank" is
always contiguous?  That's handy.

> I worried that pfn_to_page() in sparsemem is a bit slower than that in flatmem.
> Moreover, the previous one didn't use pfn_to_page() but page++ for the
> performance.
> Nevertheless, I also think that pfn_to_page() make the code neat.

The sparsemem_vmemmap pfn_to_page() is just arithmetic.  The table-based
sparsemem requires lookups and is a _bit_ slower, but the tables have
very nice CPU cache properties and shouldn't miss the L1 very often in a
loop like that.

show_mem() isn't exactly a performance-critical path, either, right?
It's just an exception or error path.

If it turns out that doing pfn_to_page() *is* too slow, there are a
couple more alternatives.  pfn_to_section_nr() is just a bit shift and
is really cheap.  Should be just an instruction or two with either no
memory access, or just a load of the pfn from the stack.

We could make a generic function like this (Or I guess we could also
just make sure that pfn_to_section_nr() always returns 0 for
non-sparsemem configurations):

int pfns_same_section(unsigned long pfn1, unsigned long pfn2)
	return (pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2));
	return 1;

and use it in show_mem like so:

                do {
                        if (PageReserved(page))
                        else if (PageSwapCache(page))
                        else if (PageSlab(page))
                        else if (!page_count(page))
                                shared += page_count(page) - 1;
			 * Did we just cross a section boundary?
			 * If so, our pointer arithmetic is not
			 * valid, and we must re-run pfn_to_page()
			if (pfns_same_section(pfn1-1, pfn1)) {
			} else {
				page = pfn_to_page(pfn1);
                } while (page < end);

We can do basically the same thing, but instead checking to see if we
crossed a MAX_ORDER boundary.  That would keep us from having to refer
to sparsemem at all.  The buddy allocator relies on that guarantee, so
it's pretty set in stone.

-- Dave

  parent reply	other threads:[~2011-01-20 18:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-20  9:45 KyongHo Cho
2011-01-20 14:28 ` Minchan Kim
2011-01-20 17:25   ` Dave Hansen
     [not found]   ` <>
2011-01-20 17:43     ` Minchan Kim
2011-01-20 17:44       ` Minchan Kim
2011-01-20 17:52         ` KyongHo Cho
2011-01-20 17:20 ` Dave Hansen
     [not found]   ` <>
2011-01-20 17:48     ` KyongHo Cho
2011-01-20 18:04     ` Dave Hansen [this message]
2011-01-20 18:01   ` Russell King - ARM Linux
2011-01-20 18:11     ` Dave Hansen
2011-01-23 18:05       ` Russell King - ARM Linux
2011-01-24 16:52         ` Dave Hansen
2011-01-24 17:58           ` Russell King - ARM Linux
2011-01-24 18:47             ` Dave Hansen
2011-01-25  0:33             ` KyongHo Cho
2011-01-21  2:12     ` KyongHo Cho
2011-01-21 10:38       ` Russell King - ARM Linux
2011-01-21 11:15         ` KyongHo Cho

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295546653.9039.680.camel@nimitz \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] ARM: mm: Regarding section when dealing with meminfo' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).