From: Zhang Yanfei <zhangyanfei.yes@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>,
rjw@sisk.pl, lenb@kernel.org, tglx@linutronix.de, mingo@elte.hu,
hpa@zytor.com, akpm@linux-foundation.org, toshi.kani@hp.com,
zhangyanfei@cn.fujitsu.com, liwanp@linux.vnet.ibm.com,
trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, laijs@cn.fujitsu.com,
isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
mgorman@suse.de, minchan@kernel.org, mina86@mina86.com,
gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com,
lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com,
prarit@redhat.com, x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH v3 2/5] memblock: Improve memblock to support allocation from lower address.
Date: Tue, 24 Sep 2013 02:07:13 +0800 [thread overview]
Message-ID: <52408351.8080400@gmail.com> (raw)
In-Reply-To: <20130923155027.GD14547@htj.dyndns.org>
Hello tejun,
On 09/23/2013 11:50 PM, Tejun Heo wrote:
> Hello,
>
> Please separate out factoring out of top-down allocation. That change
> is an equivalent conversion which shouldn't involve any functional
> difference. Mixing that with introduction of new feature isn't a good
> idea, so the patch split should be 1. split out top-down allocation
> from memblock_find_in_range_node() 2. introduce bottom-up flag and
> implement the feature.
>
> On Fri, Sep 13, 2013 at 05:30:52PM +0800, Tang Chen wrote:
>> +/**
>> * memblock_find_in_range_node - find free area in given range and node
>> - * @start: start of candidate range
>> + * @start: start of candidate range, can be %MEMBLOCK_ALLOC_ACCESSIBLE
>
> The only reason @end has special ACCESSIBLE flag is because we don't
> know how high is actually accessible and it needs to be distinguished
> from ANYWHERE. We assume that the lower addresses are always mapped,
> so using ACCESSIBLE for @start is weird. I think it'd be clearer to
> make the memblock interface to set the direction explicitly state what
> it's doing - ie. something like set_memblock_alloc_above_kernel(bool
> enable). We clearly don't want pure bottom-up allocation and the
> @start/@end params in memblock interface are used to impose extra
> limitations for each allocation, not the overall allocator behavior.
Forgot this one...
Yes, I am following your advice in principle but kind of confused by
something you said above. Where should the set_memblock_alloc_above_kernel
be used? IMO, the function is like:
find_in_range_node()
{
if (ok) {
/* bottom-up */
ret = __memblock_find_in_range(max(start, _end_of_kernel), end...);
if (!ret)
return ret;
}
/* top-down retry */
return __memblock_find_in_range_rev(start, end...)
}
For bottom-up allocation, we always start from max(start, _end_of_kernel).
Thanks.
>
>> @@ -100,8 +180,7 @@ 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)
>> {
>> - phys_addr_t this_start, this_end, cand;
>> - u64 i;
>> + phys_addr_t ret;
>>
>> /* pump up @end */
>> if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>> @@ -111,18 +190,22 @@ 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);
>>
>> - for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
>> - this_start = clamp(this_start, start, end);
>> - this_end = clamp(this_end, start, end);
>> + if (memblock_direction_bottom_up()) {
>> + /*
>> + * MEMBLOCK_ALLOC_ACCESSIBLE is 0, which is less than the end
>> + * of kernel image. So callers specify MEMBLOCK_ALLOC_ACCESSIBLE
>> + * as @start is OK.
>> + */
>> + start = max(start, __pa_symbol(_end)); /* End of kernel image. */
>>
>> - if (this_end < size)
>> - continue;
>> + ret = __memblock_find_range(start, end, size, align, nid);
>> + if (ret)
>> + return ret;
>>
>> - cand = round_down(this_end - size, align);
>> - if (cand >= this_start)
>> - return cand;
>> + pr_warn("memblock: Failed to allocate memory in bottom up direction. Now try top down direction.\n");
>
> You probably wanna explain why retrying top-down allocation may
> succeed when bottom-up failed.
>
> Thanks.
>
--
Thanks.
Zhang Yanfei
WARNING: multiple messages have this Message-ID (diff)
From: Zhang Yanfei <zhangyanfei.yes@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>,
rjw@sisk.pl, lenb@kernel.org, tglx@linutronix.de, mingo@elte.hu,
hpa@zytor.com, akpm@linux-foundation.org, toshi.kani@hp.com,
zhangyanfei@cn.fujitsu.com, liwanp@linux.vnet.ibm.com,
trenn@suse.de, yinghai@kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, laijs@cn.fujitsu.com,
isimatu.yasuaki@jp.fujitsu.com, izumi.taku@jp.fujitsu.com,
mgorman@suse.de, minchan@kernel.org, mina86@mina86.com,
gong.chen@linux.intel.com, vasilis.liaskovitis@profitbricks.com,
lwoodman@redhat.com, riel@redhat.com, jweiner@redhat.com,
prarit@redhat.com, x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH v3 2/5] memblock: Improve memblock to support allocation from lower address.
Date: Tue, 24 Sep 2013 02:07:13 +0800 [thread overview]
Message-ID: <52408351.8080400@gmail.com> (raw)
In-Reply-To: <20130923155027.GD14547@htj.dyndns.org>
Hello tejun,
On 09/23/2013 11:50 PM, Tejun Heo wrote:
> Hello,
>
> Please separate out factoring out of top-down allocation. That change
> is an equivalent conversion which shouldn't involve any functional
> difference. Mixing that with introduction of new feature isn't a good
> idea, so the patch split should be 1. split out top-down allocation
> from memblock_find_in_range_node() 2. introduce bottom-up flag and
> implement the feature.
>
> On Fri, Sep 13, 2013 at 05:30:52PM +0800, Tang Chen wrote:
>> +/**
>> * memblock_find_in_range_node - find free area in given range and node
>> - * @start: start of candidate range
>> + * @start: start of candidate range, can be %MEMBLOCK_ALLOC_ACCESSIBLE
>
> The only reason @end has special ACCESSIBLE flag is because we don't
> know how high is actually accessible and it needs to be distinguished
> from ANYWHERE. We assume that the lower addresses are always mapped,
> so using ACCESSIBLE for @start is weird. I think it'd be clearer to
> make the memblock interface to set the direction explicitly state what
> it's doing - ie. something like set_memblock_alloc_above_kernel(bool
> enable). We clearly don't want pure bottom-up allocation and the
> @start/@end params in memblock interface are used to impose extra
> limitations for each allocation, not the overall allocator behavior.
Forgot this one...
Yes, I am following your advice in principle but kind of confused by
something you said above. Where should the set_memblock_alloc_above_kernel
be used? IMO, the function is like:
find_in_range_node()
{
if (ok) {
/* bottom-up */
ret = __memblock_find_in_range(max(start, _end_of_kernel), end...);
if (!ret)
return ret;
}
/* top-down retry */
return __memblock_find_in_range_rev(start, end...)
}
For bottom-up allocation, we always start from max(start, _end_of_kernel).
Thanks.
>
>> @@ -100,8 +180,7 @@ 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)
>> {
>> - phys_addr_t this_start, this_end, cand;
>> - u64 i;
>> + phys_addr_t ret;
>>
>> /* pump up @end */
>> if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>> @@ -111,18 +190,22 @@ 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);
>>
>> - for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
>> - this_start = clamp(this_start, start, end);
>> - this_end = clamp(this_end, start, end);
>> + if (memblock_direction_bottom_up()) {
>> + /*
>> + * MEMBLOCK_ALLOC_ACCESSIBLE is 0, which is less than the end
>> + * of kernel image. So callers specify MEMBLOCK_ALLOC_ACCESSIBLE
>> + * as @start is OK.
>> + */
>> + start = max(start, __pa_symbol(_end)); /* End of kernel image. */
>>
>> - if (this_end < size)
>> - continue;
>> + ret = __memblock_find_range(start, end, size, align, nid);
>> + if (ret)
>> + return ret;
>>
>> - cand = round_down(this_end - size, align);
>> - if (cand >= this_start)
>> - return cand;
>> + pr_warn("memblock: Failed to allocate memory in bottom up direction. Now try top down direction.\n");
>
> You probably wanna explain why retrying top-down allocation may
> succeed when bottom-up failed.
>
> 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>
next prev parent reply other threads:[~2013-09-23 18:07 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 9:30 [PATCH v3 0/5] x86, memblock: Allocate memory near kernel image before SRAT parsed Tang Chen
2013-09-13 9:30 ` Tang Chen
2013-09-13 9:30 ` [PATCH v3 1/5] memblock: Introduce allocation direction to memblock Tang Chen
2013-09-13 9:30 ` Tang Chen
2013-09-14 2:42 ` Jianguo Wu
2013-09-14 2:42 ` Jianguo Wu
2013-09-14 2:42 ` Jianguo Wu
2013-09-15 13:23 ` chen tang
2013-09-15 13:23 ` chen tang
2013-09-23 15:38 ` Tejun Heo
2013-09-23 15:38 ` Tejun Heo
2013-09-23 16:36 ` Zhang Yanfei
2013-09-23 16:36 ` Zhang Yanfei
2013-09-13 9:30 ` [PATCH v3 2/5] memblock: Improve memblock to support allocation from lower address Tang Chen
2013-09-13 9:30 ` Tang Chen
2013-09-13 21:53 ` Toshi Kani
2013-09-13 21:53 ` Toshi Kani
2013-09-16 1:28 ` Zhang Yanfei
2013-09-16 1:28 ` Zhang Yanfei
2013-09-23 15:50 ` Tejun Heo
2013-09-23 15:50 ` Tejun Heo
2013-09-23 16:44 ` Zhang Yanfei
2013-09-23 16:44 ` Zhang Yanfei
2013-09-23 18:07 ` Zhang Yanfei [this message]
2013-09-23 18:07 ` Zhang Yanfei
2013-09-23 20:21 ` Tejun Heo
2013-09-23 20:21 ` Tejun Heo
2013-09-24 2:41 ` Zhang Yanfei
2013-09-24 2:41 ` Zhang Yanfei
2013-09-24 2:46 ` Tejun Heo
2013-09-24 2:46 ` Tejun Heo
2013-09-13 9:30 ` [PATCH v3 3/5] x86, acpi, crash, kdump: Do reserve_crashkernel() after SRAT is parsed Tang Chen
2013-09-13 9:30 ` Tang Chen
2013-09-13 9:30 ` [PATCH v3 4/5] x86, mem-hotplug: Support initialize page tables from low to high Tang Chen
2013-09-13 9:30 ` Tang Chen
2013-09-23 15:53 ` Tejun Heo
2013-09-23 15:53 ` Tejun Heo
2013-09-23 16:46 ` Zhang Yanfei
2013-09-23 16:46 ` Zhang Yanfei
2013-09-13 9:30 ` [PATCH v3 5/5] mem-hotplug: Introduce movablenode boot option to control memblock allocation direction Tang Chen
2013-09-13 9:30 ` Tang Chen
2013-09-23 15:57 ` Tejun Heo
2013-09-23 15:57 ` Tejun Heo
2013-09-23 16:58 ` Zhang Yanfei
2013-09-23 16:58 ` Zhang Yanfei
2013-09-23 17:11 ` Tejun Heo
2013-09-23 17:11 ` Tejun Heo
2013-09-16 11:00 ` [PATCH v3 0/5] x86, memblock: Allocate memory near kernel image before SRAT parsed Zhang Yanfei
2013-09-16 11:00 ` Zhang Yanfei
2013-09-19 16:57 ` Yanfei Zhang
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=52408351.8080400@gmail.com \
--to=zhangyanfei.yes@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gong.chen@linux.intel.com \
--cc=hpa@zytor.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=tangchen@cn.fujitsu.com \
--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 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.