linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: akpm@linux-foundation.org
Cc: mm-commits@vger.kernel.org, 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, 10 Sep 2012 10:22:39 +0200	[thread overview]
Message-ID: <20120910082035.GA13035@dhcp22.suse.cz> (raw)
In-Reply-To: <20120907235058.A33F75C0219@hpza9.eem.corp.google.com>

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

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>

       reply	other threads:[~2012-09-10  8:22 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 ` Michal Hocko [this message]
2012-09-10  9:46   ` + mm-memblock-reduce-overhead-in-binary-search.patch added to -mm tree Wanpeng Li
2012-09-10 11:05     ` Michal Hocko
2012-09-10 11:30       ` Wanpeng Li
2012-09-10 11:55         ` Michal Hocko
2012-10-08 19:42           ` Andrew Morton
2012-12-18 23:11             ` Andrew Morton
2012-09-10 11:30       ` Wanpeng Li
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=20120910082035.GA13035@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=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=minchan@kernel.org \
    --cc=mm-commits@vger.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).