From: Tejun Heo <tj@kernel.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: 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: Mon, 23 Sep 2013 11:50:27 -0400 [thread overview]
Message-ID: <20130923155027.GD14547@htj.dyndns.org> (raw)
In-Reply-To: <1379064655-20874-3-git-send-email-tangchen@cn.fujitsu.com>
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.
> @@ -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.
--
tejun
--
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 16:20 UTC|newest]
Thread overview: 25+ 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 ` [PATCH v3 1/5] memblock: Introduce allocation direction to memblock Tang Chen
2013-09-14 2:42 ` Jianguo Wu
2013-09-15 13:23 ` chen tang
2013-09-23 15:38 ` Tejun Heo
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 21:53 ` Toshi Kani
2013-09-16 1:28 ` Zhang Yanfei
2013-09-23 15:50 ` Tejun Heo [this message]
2013-09-23 16:44 ` Zhang Yanfei
2013-09-23 18:07 ` Zhang Yanfei
2013-09-23 20:21 ` Tejun Heo
2013-09-24 2:41 ` Zhang Yanfei
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 ` [PATCH v3 4/5] x86, mem-hotplug: Support initialize page tables from low to high Tang Chen
2013-09-23 15:53 ` Tejun Heo
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-23 15:57 ` Tejun Heo
2013-09-23 16:58 ` Zhang Yanfei
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-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=20130923155027.GD14547@htj.dyndns.org \
--to=tj@kernel.org \
--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=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).