linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zhang Yanfei <zhangyanfei.yes@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
	"Rafael J . Wysocki" <rjw@sisk.pl>,
	lenb@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	mingo@elte.hu, "H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Toshi Kani <toshi.kani@hp.com>,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>,
	Thomas Renninger <trenn@suse.de>, Yinghai Lu <yinghai@kernel.org>,
	Jiang Liu <jiang.liu@huawei.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
	Mel Gorman <mgorman@suse.de>, Minchan Kim <minchan@kernel.org>,
	mina86@mina86.com, gong.chen@linux.intel.com,
	vasilis.liaskovitis@profitbricks.com, lwoodman@redhat.com,
	Rik van Riel <riel@redhat.com>,
	jweiner@redhat.com, prarit@redhat.com,
	"x86@kernel.org" <x86@kernel.org>,
	linux-doc@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	linux-acpi@vger.kernel.org, imtangchen@gmail.com
Subject: Re: [PATCH 2/6] memblock: Introduce bottom-up allocation mode
Date: Tue, 24 Sep 2013 21:17:16 +0800	[thread overview]
Message-ID: <524190DC.4060605@gmail.com> (raw)
In-Reply-To: <20130924121725.GC2366@htj.dyndns.org>

Hello tejun,

On 09/24/2013 08:17 PM, Tejun Heo wrote:
> On Tue, Sep 24, 2013 at 06:05:03PM +0800, Zhang Yanfei wrote:
>> +/* Allocation direction */
>> +enum {
>> +	MEMBLOCK_DIRECTION_TOP_DOWN,
>> +	MEMBLOCK_DIRECTION_BOTTOM_UP,
>> +	NR_MEMLBOCK_DIRECTIONS
>> +};
>> +
>>  struct memblock_region {
>>  	phys_addr_t base;
>>  	phys_addr_t size;
>> @@ -35,6 +42,7 @@ struct memblock_type {
>>  };
>>  
>>  struct memblock {
>> +	int current_direction;  /* current allocation direction */
> 
> Just use boolean bottom_up here too?  No need for the constants.

OKay. Will try this way.

> 
>> @@ -20,6 +20,8 @@
>>  #include <linux/seq_file.h>
>>  #include <linux/memblock.h>
>>  
>> +#include <asm-generic/sections.h>
>> +
> 
> Why is the above added by this patch?

Oh, we use _end in this file which is defined in that header file.

> 
>>  /**
>> + * __memblock_find_range - find free area utility
>> + * @start: start of candidate range
>> + * @end: end of candidate range, can be %MEMBLOCK_ALLOC_{ANYWHERE|ACCESSIBLE}
>> + * @size: size of free area to find
>> + * @align: alignment of free area to find
>> + * @nid: nid of the free area to find, %MAX_NUMNODES for any node
>> + *
>> + * Utility called from memblock_find_in_range_node(), find free area bottom-up.
>> + *
>> + * RETURNS:
>> + * Found address on success, %0 on failure.
> 
> I don't think we prefix numeric literals with %.

OKay. Will remove %

> 
> ...
>> @@ -127,6 +162,10 @@ __memblock_find_range_rev(phys_addr_t start, phys_addr_t end,
>>   *
>>   * Find @size free area aligned to @align in the specified range and node.
>>   *
>> + * When allocation direction is bottom-up, the @start should be greater
>> + * than the end of the kernel image. Otherwise, it will be trimmed. And also,
>> + * if bottom-up allocation failed, will try to allocate memory top-down.
> 
> It'd be nice to explain that bottom-up allocation is limited to above
> kernel image and what it's used for here.

OK. Will add the comment.

> 
>> + *
>>   * RETURNS:
>>   * Found address on success, %0 on failure.
>>   */
>> @@ -134,6 +173,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>>  					phys_addr_t end, phys_addr_t size,
>>  					phys_addr_t align, int nid)
>>  {
>> +	int ret;
>> +
>>  	/* pump up @end */
>>  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>>  		end = memblock.current_limit;
>> @@ -142,6 +183,28 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>>  	start = max_t(phys_addr_t, start, PAGE_SIZE);
>>  	end = max(start, end);
>>  
>> +	if (memblock_bottom_up()) {
>> +		phys_addr_t bottom_up_start;
>> +
>> +		/* make sure we will allocate above the kernel */
>> +		bottom_up_start = max_t(phys_addr_t, start, __pa_symbol(_end));
>> +
>> +		/* ok, try bottom-up allocation first */
>> +		ret = __memblock_find_range(bottom_up_start, end,
>> +					    size, align, nid);
>> +		if (ret)
>> +			return ret;
>> +
>> +		/*
>> +		 * we always limit bottom-up allocation above the kernel,
>> +		 * but top-down allocation doesn't have the limit, so
>> +		 * retrying top-down allocation may succeed when bottom-up
>> +		 * allocation failed.
>> +		 */
>> +		pr_warn("memblock: Failed to allocate memory in bottom up "
>> +			"direction. Now try top down direction.\n");
> 
> Maybe just print warning only on the first failure?

Hmmm... This message is for each memblock allocation, that said, if the
allocation this time fails, it prints the message and we use so called top-down.
But next time, we still use bottom up first again.

Did you mean if we fail on one bottom-up allocation, then we never try
bottom-up again and will always use top-down? 

Thanks. 

> 
> Otherwise, looks good to me.
> 
> Thanks.
> 


-- 
Thanks.
Zhang Yanfei

--
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:[~2013-09-24 13:17 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 10:00 [PATCH v4 0/6] x86, memblock: Allocate memory near kernel image before SRAT parsed Zhang Yanfei
2013-09-24 10:03 ` [PATCH 1/6] memblock: Factor out of top-down allocation Zhang Yanfei
2013-09-24 12:10   ` Tejun Heo
2013-09-24 13:04     ` Zhang Yanfei
2013-09-24 10:05 ` [PATCH 2/6] memblock: Introduce bottom-up allocation mode Zhang Yanfei
2013-09-24 12:17   ` Tejun Heo
2013-09-24 13:17     ` Zhang Yanfei [this message]
2013-09-24 13:23       ` Tejun Heo
2013-09-24 14:12         ` Zhang Yanfei
2013-09-24 14:16           ` Tejun Heo
2013-09-24 14:19             ` Zhang Yanfei
2013-09-24 10:06 ` [PATCH 3/6] x86/mm: Factor out of top-down direct mapping setup Zhang Yanfei
2013-09-24 12:27   ` Tejun Heo
2013-09-24 13:20     ` Zhang Yanfei
2013-09-24 10:08 ` [PATCH 4/6] x86/mem-hotplug: Support initialize page tables bottom up Zhang Yanfei
2013-09-24 12:33   ` Tejun Heo
2013-09-24 13:23     ` Zhang Yanfei
2013-09-24 13:27       ` Tejun Heo
2013-09-24 13:34         ` Zhang Yanfei
2013-09-24 13:39           ` Tejun Heo
2013-09-24 13:53             ` Zhang Yanfei
2013-09-24 14:05               ` Tejun Heo
2013-09-24 14:07                 ` Zhang Yanfei
2013-09-24 10:09 ` [PATCH 5/6] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed Zhang Yanfei
2013-09-24 12:34   ` Tejun Heo
2013-09-24 13:24     ` Zhang Yanfei
2013-09-24 10:11 ` [PATCH 6/6] mem-hotplug: Introduce movablenode boot option Zhang Yanfei
2013-09-24 12:41   ` Tejun Heo
2013-09-24 13:31     ` Zhang Yanfei
2013-09-24 15:24       ` Zhang Yanfei
2013-09-24 15:32         ` Tejun Heo
2013-09-24 15:43           ` Zhang Yanfei
2013-09-24 16:00         ` Toshi Kani
2013-09-24 16:08           ` Zhang Yanfei
2013-09-24 16:33             ` Toshi Kani

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=524190DC.4060605@gmail.com \
    --to=zhangyanfei.yes@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=gong.chen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=imtangchen@gmail.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=jweiner@redhat.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=lwoodman@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.org \
    --cc=mingo@elte.hu \
    --cc=prarit@redhat.com \
    --cc=riel@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=toshi.kani@hp.com \
    --cc=trenn@suse.de \
    --cc=vasilis.liaskovitis@profitbricks.com \
    --cc=wency@cn.fujitsu.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    --cc=zhangyanfei@cn.fujitsu.com \
    /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).