[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51EF7ADD.6050500@cn.fujitsu.com>
Date: Wed, 24 Jul 2013 14:57:33 +0800
From: Tang Chen <tangchen@...fujitsu.com>
To: Tejun Heo <tj@...nel.org>
CC: 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,
yanghy@...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 12/21] x86, acpi: Try to find if SRAT is overrided earlier.
On 07/24/2013 04:27 AM, Tejun Heo wrote:
> On Fri, Jul 19, 2013 at 03:59:25PM +0800, Tang Chen wrote:
>> As we mentioned in previous patches, to prevent the kernel
>
> Prolly best to briefly describe what the overall goal is about.
Sure. Here is the overall picture, and will add it to log.
Linux cannot migrate pages used by the kernel due to the direct mapping
(va = pa + PAGE_OFFSET), any memory used by the kernel cannot be
hot-removed.
So in memory hotplug platform, we have to prevent the kernel from using
hotpluggable memory.
The ACPI table SRAT (System Resource Affinity Table) contains info to
specify
which memory is hotpluggble. After SRAT is parsed, we are aware of which
memory is hotpluggable.
At the early time when system is booting, SRAT has not been parsed. The boot
memory allocator memblock will allocate any memory to the kernel. So we need
SRAT parsed before memblock starts to work.
In this patch, we are going to parse SRAT earlier, right after memblock
is ready.
Generally speaking, SRAT is provided by firmware. But
ACPI_INITRD_TABLE_OVERRIDE
functionality allows users to customize their own SRAT in initrd, and
override
the one from firmware. So if we want to parse SRAT earlier, we also need
to do
SRAT override earlier.
First, we introduce early_acpi_override_srat() to check if SRAT will be
overridden
from initrd.
Second, we introduce reserve_hotpluggable_memory() to reserve
hotpluggable memory,
which will firstly call early_acpi_override_srat() to find out which
memory is
hotpluggable in the override SRAT.
>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 28d2e60..9717760 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -1078,6 +1078,15 @@ void __init setup_arch(char **cmdline_p)
>> /* Initialize ACPI root table */
>> acpi_root_table_init();
>>
>> +#ifdef CONFIG_ACPI_NUMA
>> + /*
>> + * Linux kernel cannot migrate kernel pages, as a result, memory used
>> + * by the kernel cannot be hot-removed. Reserve hotpluggable memory to
>> + * prevent memblock from allocating hotpluggable memory for the kernel.
>> + */
>> + reserve_hotpluggable_memory();
>> +#endif
>
> Hmmm, so you're gonna reserve all hotpluggable memory areas until
> everything is up and running, which probably is why allocating
> node_data on hotpluggable node doesn't work, right?
Yes, that's right. The node_data of hotpluggable node is now put on another
unhotpluggable node.
>
......
>> +phys_addr_t __init early_acpi_override_srat(void)
>> +{
>> + int i;
>> + u32 length;
>> + long offset;
>> + void *ramdisk_vaddr;
>> + struct acpi_table_header *table;
>> + unsigned long map_step = NR_FIX_BTMAPS<< PAGE_SHIFT;
>> + phys_addr_t ramdisk_image = get_ramdisk_image();
>> + char cpio_path[32] = "kernel/firmware/acpi/";
>> + struct cpio_data file;
>
> Don't we usually put variable declarations with initializers before
> others? For some reason, the above block is painful to look at.
OK, followed.
Thanks.
--
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