[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130828151909.GE9295@htj.dyndns.org>
Date: Wed, 28 Aug 2013 11:19:09 -0400
From: Tejun Heo <tj@...nel.org>
To: Tang Chen <tangchen@...fujitsu.com>
Cc: rjw@...k.pl, lenb@...nel.org, tglx@...utronix.de, mingo@...e.hu,
hpa@...or.com, akpm@...ux-foundation.org, trenn@...e.de,
yinghai@...nel.org, jiang.liu@...wei.com, wency@...fujitsu.com,
laijs@...fujitsu.com, isimatu.yasuaki@...fujitsu.com,
izumi.taku@...fujitsu.com, mgorman@...e.de, minchan@...nel.org,
mina86@...a86.com, gong.chen@...ux.intel.com,
vasilis.liaskovitis@...fitbricks.com, lwoodman@...hat.com,
riel@...hat.com, jweiner@...hat.com, prarit@...hat.com,
zhangyanfei@...fujitsu.com, x86@...nel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 00/11] x86, memblock: Allocate memory near kernel image
before SRAT parsed.
On Tue, Aug 27, 2013 at 05:37:37PM +0800, Tang Chen wrote:
> Tang Chen (11):
> memblock: Rename current_limit to current_limit_high in memblock.
> memblock: Rename memblock_set_current_limit() to
> memblock_set_current_limit_high().
> memblock: Introduce lowest limit in memblock.
> memblock: Introduce memblock_set_current_limit_low() to set lower
> limit of memblock.
> memblock: Introduce allocation order to memblock.
> memblock: Improve memblock to support allocation from lower address.
> x86, memblock: Set lowest limit for memblock_alloc_base_nid().
> x86, acpi, memblock: Use __memblock_alloc_base() in
> acpi_initrd_override()
> mem-hotplug: Introduce movablenode boot option to {en|dis}able using
> SRAT.
> x86, mem-hotplug: Support initialize page tables from low to high.
> x86, mem_hotplug: Allocate memory near kernel image before SRAT is
> parsed.
Doesn't apply to -master, -next or tip. Again, can you please include
which tree and git commit the patches are against in the patch
description? How is one supposed to know on top of which tree you're
working? It is in your benefit to make things easier for the prosepct
reviewers. Trying to guess and apply the patches to different devel
branches and failing isn't productive and frustates your prospect
reviewers who would of course have negative pre-perception going into
the review and this isn't the first time this issue was raised either.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists