From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.cz>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
kamezawa.hiroyu@jp.fujitsu.com, minchan@kernel.org,
shangw@linux.vnet.ibm.com, yinghai@kernel.org,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: + mm-memblock-reduce-overhead-in-binary-search.patch added to -mm tree
Date: Tue, 18 Dec 2012 15:11:39 -0800 [thread overview]
Message-ID: <20121218151139.c1126afb.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121008124234.3e8c511b.akpm@linux-foundation.org>
On Mon, 8 Oct 2012 12:42:34 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 10 Sep 2012 13:55:15 +0200
> Michal Hocko <mhocko@suse.cz> wrote:
>
> > > >OK. Thanks for the clarification. The main question remains, though. Is
> > > >this worth for memblock_is_memory?
> > >
> > > There are many call sites need to call pfn_valid, how can you guarantee all
> > > the addrs are between memblock_start_of_DRAM() and memblock_end_of_DRAM(),
> > > if not can this reduce possible overhead ?
> >
> > That was my question. I hoped for an answer in the patch description. I
> > am really not familiar with unicore32 which is the only user now.
> >
> > > I add unlikely which means that this will not happen frequently. :-)
> >
> > unlikely doesn't help much in this case. You would be doing the test for
> > every pfn_valid invocation anyway. So the main question is. Do you want
> > to optimize for something that doesn't happen often when it adds a cost
> > (not a big one but still) for the more probable cases?
> > I would say yes if we clearly see that the exceptional case really pays
> > off. Nothing in the changelog convinces me about that.
>
> I don't believe Michal's questions have been resolved yet, so I'll keep
> this patch on hold for now.
ETIMEDOUT. I'll drop the patch. Please resend if you think it's still
needed and if these questions can be addressed.
prev parent reply other threads:[~2012-12-18 23:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120907235058.A33F75C0219@hpza9.eem.corp.google.com>
2012-09-10 8:22 ` + mm-memblock-reduce-overhead-in-binary-search.patch added to -mm tree Michal Hocko
[not found] ` <20120910094604.GA7365@hacker.(null)>
2012-09-10 11:05 ` Michal Hocko
[not found] ` <20120910113051.GA15193@hacker.(null)>
2012-09-10 11:55 ` Michal Hocko
2012-10-08 19:42 ` Andrew Morton
2012-12-18 23:11 ` Andrew Morton [this message]
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=20121218151139.c1126afb.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwanp@linux.vnet.ibm.com \
--cc=mhocko@suse.cz \
--cc=minchan@kernel.org \
--cc=shangw@linux.vnet.ibm.com \
--cc=yinghai@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