From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
jan sonnek <ha2nny@gmail.com>,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andy Whitcroft <apw@shadowen.org>
Subject: Re: Regression - locking (all from 2.6.28)
Date: Wed, 04 Mar 2009 16:54:12 -0800 [thread overview]
Message-ID: <1236214452.22399.68.camel@nimitz> (raw)
In-Reply-To: <1236092480.8547.67.camel@pc1117.cambridge.arm.com>
On Tue, 2009-03-03 at 15:01 +0000, Catalin Marinas wrote:
> > + /* mem_map scanning */
> > + for_each_online_node(i) {
> > + struct page *page, *end;
> > +
> > + page = NODE_MEM_MAP(i);
> > + end = page + NODE_DATA(i)->node_spanned_pages;
> > +
> > + scan_block(page, end, NULL);
> > + }
> >
> > The alternative is to inform kmemleak about the page structures returned
> > from __alloc_pages_internal() but there would be problems with recursive
> > calls into kmemleak when it allocates its own data structures.
> >
> > I'll look at re-adding the hunk above, maybe with some extra checks like
> > pfn_valid().
>
> Looking again at this, the node_mem_map is always contiguous and the
> code above only scans the node_mem_map, not the memory represented by
> the node (which may not be contiguous). So I think it is a valid code
> sequence.
The above is *not* a valid code sequence.
It is valid with discontig, but isn't valid for sparsemem. You simply
can't expect to do math on 'struct page' pointers for any granularity
larger than MAX_ORDER_NR_PAGES.
Also, we don't even define NODE_MEM_MAP() for all configurations so that
code snippet won't even compile. We would be smart to kill that macro.
One completely unoptimized thing you can do which will scan a 'struct
page' at a time is this:
for_each_online_node(i) {
unsigned long pfn;
for (pfn = node_start_pfn(i); pfn < node_end_pfn(i); pfn++) {
struct page *page;
if (!pfn_valid(pfn))
continue;
page = pfn_to_page(pfn);
scan_block(page, page+1, NULL);
}
}
The way to optimize it would be to call scan_block() only once for each
MAX_ORDER_NR_PAGES that you encounter. The other option would be to use
the active_regions functions to walk the memory.
Is there a requirement to reduce the number of calls to scan_block()
here?
-- Dave
next prev parent reply other threads:[~2009-03-05 0:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49AC334A.9030800@gmail.com>
2009-03-02 20:11 ` Regression - locking (all from 2.6.28) Andrew Morton
2009-03-03 10:41 ` Catalin Marinas
2009-03-03 15:01 ` Catalin Marinas
2009-03-05 0:54 ` Dave Hansen [this message]
2009-03-05 18:04 ` Catalin Marinas
2009-03-05 18:29 ` Peter Zijlstra
2009-03-06 16:40 ` Catalin Marinas
2009-03-06 16:52 ` Dave Hansen
2009-03-06 17:18 ` Catalin Marinas
2009-03-06 17:26 ` Dave Hansen
2009-03-06 18:00 ` Catalin Marinas
2009-03-06 19:19 ` Dave Hansen
2009-03-06 19:28 ` Pavel Machek
2009-03-16 22:04 ` Rafael J. Wysocki
2009-03-17 0:07 ` KAMEZAWA Hiroyuki
2009-03-14 16:24 ` Pavel Machek
2009-03-16 17:12 ` Catalin Marinas
2009-03-03 18:12 ` Peter Zijlstra
2009-03-22 4:45 jan sonnek
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=1236214452.22399.68.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=catalin.marinas@arm.com \
--cc=ha2nny@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.