All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: 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: Mon, 8 Oct 2012 12:42:34 -0700	[thread overview]
Message-ID: <20121008124234.3e8c511b.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120910115514.GC17437@dhcp22.suse.cz>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: 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: Mon, 8 Oct 2012 12:42:34 -0700	[thread overview]
Message-ID: <20121008124234.3e8c511b.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120910115514.GC17437@dhcp22.suse.cz>

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.


  reply	other threads:[~2012-10-08 19:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-07 23:50 + mm-memblock-reduce-overhead-in-binary-search.patch added to -mm tree akpm
2012-09-10  8:22 ` Michal Hocko
2012-09-10  8:22   ` Michal Hocko
2012-09-10  9:46   ` Wanpeng Li
2012-09-10 11:05     ` Michal Hocko
2012-09-10 11:05       ` Michal Hocko
2012-09-10 11:30       ` Wanpeng Li
2012-09-10 11:30       ` Wanpeng Li
2012-09-10 11:55         ` Michal Hocko
2012-09-10 11:55           ` Michal Hocko
2012-10-08 19:42           ` Andrew Morton [this message]
2012-10-08 19:42             ` Andrew Morton
2012-12-18 23:11             ` Andrew Morton
2012-12-18 23:11               ` Andrew Morton
2012-09-10  9:46   ` Wanpeng Li
  -- strict thread matches above, loose matches on Subject: below --
2012-08-24 21:48 akpm

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=20121008124234.3e8c511b.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 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.