linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wanpeng Li <liwanp@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: akpm@linux-foundation.org, 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, 10 Sep 2012 19:30:51 +0800	[thread overview]
Message-ID: <20120910113051.GA15193@hacker.(null)> (raw)
In-Reply-To: <20120910110550.GA17437@dhcp22.suse.cz>

On Mon, Sep 10, 2012 at 01:05:50PM +0200, Michal Hocko wrote:
>On Mon 10-09-12 17:46:04, Wanpeng Li wrote:
>> On Mon, Sep 10, 2012 at 10:22:39AM +0200, Michal Hocko wrote:
>> >[Sorry for the late reply]
>> >
>> >On Fri 07-09-12 16:50:57, Andrew Morton wrote:
>> >> 
>> >> The patch titled
>> >>      Subject: mm/memblock: reduce overhead in binary search
>> >> has been added to the -mm tree.  Its filename is
>> >>      mm-memblock-reduce-overhead-in-binary-search.patch
>> >> 
>> >> Before you just go and hit "reply", please:
>> >>    a) Consider who else should be cc'ed
>> >>    b) Prefer to cc a suitable mailing list as well
>> >>    c) Ideally: find the original patch on the mailing list and do a
>> >>       reply-to-all to that, adding suitable additional cc's
>> >> 
>> >> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>> >> 
>> >> The -mm tree is included into linux-next and is updated
>> >> there every 3-4 working days
>> >> 
>> >> ------------------------------------------------------
>> >> From: Wanpeng Li <liwanp@linux.vnet.ibm.com>
>> >> Subject: mm/memblock: reduce overhead in binary search
>> >> 
>> >> When checking that the indicated address belongs to the memory region, the
>> >> memory regions are checked one by one through a binary search, which will
>> >> be time consuming.
>> >
>> >How many blocks do you have that O(long) is that time consuming?
>> >
>> >> If the indicated address isn't in the memory region, then we needn't do
>> >> the time-consuming search.  
>> >
>> >How often does this happen?
>> >
>> >> Add a check on the indicated address for that purpose.
>> >
>> >We have 2 users of this function. One is exynos_sysmmu_enable and the
>> >other pfn_valid for unicore32. The first one doesn't seem to be used
>> >anywhere (as per git grep). The other one could benefit from it but it
>> >would be nice to hear about how much it really helps becuase if the
>> >address is (almost) never outside of start,end DRAM bounds then you just
>> >add a pointless check.
>> >Besides that, if this kind of optimization is really worth, why don't we
>> >do the same thing for memblock_is_reserved and memblock_is_region_memory
>> >as well?
>> 
>> As Yinghai said,
>> 
>> BIOS could have reserved some ranges, and those ranges are not overlapped by 
>> RAM. and so those range will not be in memory and reserved array.
>> 
>> later kernel will probe some range, and reserved those range, so those
>> range get inserted into reserved array. reserved and memory array is
>> different.
>
>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 ? I add unlikely which means that 
this will not happen frequently.  :-)

>
>> >So, while the patch seems correct, I do not see how much it helps while
>> >it definitely adds a code to maintain.
>> >
>> >> Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
>> >> Cc: Michal Hocko <mhocko@suse.cz>
>> >> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>> >> Cc: Minchan Kim <minchan@kernel.org>
>> >> Cc: Gavin Shan <shangw@linux.vnet.ibm.com>
>> >> Cc: Yinghai Lu <yinghai@kernel.org>
>> >> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> >> ---
>> >> 
>> >>  mm/memblock.c |    5 +++++
>> >>  1 file changed, 5 insertions(+)
>> >> 
>> >> diff -puN mm/memblock.c~mm-memblock-reduce-overhead-in-binary-search mm/memblock.c
>> >> --- a/mm/memblock.c~mm-memblock-reduce-overhead-in-binary-search
>> >> +++ a/mm/memblock.c
>> >> @@ -888,6 +888,11 @@ int __init memblock_is_reserved(phys_add
>> >>  
>> >>  int __init_memblock memblock_is_memory(phys_addr_t addr)
>> >>  {
>> >> +
>> >> +	if (unlikely(addr < memblock_start_of_DRAM() ||
>> >> +		addr >= memblock_end_of_DRAM()))
>> >> +		return 0;
>> >> +
>> >>  	return memblock_search(&memblock.memory, addr) != -1;
>> >>  }
>> >>  
>> >> _
>> >> 
>> >> Patches currently in -mm which might be from liwanp@linux.vnet.ibm.com are
>> >> 
>> >> mm-mmu_notifier-init-notifier-if-necessary.patch
>> >> mm-vmscan-fix-error-number-for-failed-kthread.patch
>> >> mm-memblock-reduce-overhead-in-binary-search.patch
>> >> mm-memblock-rename-get_allocated_memblock_reserved_regions_info.patch
>> >> mm-memblock-use-existing-interface-to-set-nid.patch
>> >> mm-memblock-cleanup-early_node_map-related-comments.patch
>> >> 
>> >
>> >-- 
>> >Michal Hocko
>> >SUSE Labs
>> >
>> >--
>> >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>
>> 
>
>-- 
>Michal Hocko
>SUSE Labs

--
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>

  parent reply	other threads:[~2012-09-10 11:31 UTC|newest]

Thread overview: 9+ 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
2012-09-10  9:46   ` Wanpeng Li
2012-09-10 11:05     ` Michal Hocko
2012-09-10 11:30       ` Wanpeng Li
2012-09-10 11:30       ` Wanpeng Li [this message]
2012-09-10 11:55         ` Michal Hocko
2012-10-08 19:42           ` Andrew Morton
2012-12-18 23:11             ` Andrew Morton
2012-09-10  9:46   ` Wanpeng Li

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='20120910113051.GA15193@hacker.(null)' \
    --to=liwanp@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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;
as well as URLs for NNTP newsgroup(s).