From: Tang Chen <tangchen@cn.fujitsu.com>
To: Glauber Costa <glommer@parallels.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
akpm@linux-foundation.org, rientjes@google.com, liuj97@gmail.com,
len.brown@intel.com, benh@kernel.crashing.org, paulus@samba.org,
cl@linux.com, minchan.kim@gmail.com,
kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
wujianguo@huawei.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
sparclinux@vger.kernel.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
Date: Thu, 10 Jan 2013 09:38:10 +0800 [thread overview]
Message-ID: <50EE1B82.4090601@cn.fujitsu.com> (raw)
In-Reply-To: <50ED8834.1090804@parallels.com>
Hi Glauber,
On 01/09/2013 11:09 PM, Glauber Costa wrote:
>>
>> We try to make all page_cgroup allocations local to the node they are describing
>> now. If the memory is the first memory onlined in this node, we will allocate
>> it from the other node.
>>
>> For example, node1 has 4 memory blocks: 8-11, and we online it from 8 to 11
>> 1. memory block 8, page_cgroup allocations are in the other nodes
>> 2. memory block 9, page_cgroup allocations are in memory block 8
>>
>> So we should offline memory block 9 first. But we don't know in which order
>> the user online the memory block.
>>
>> I think we can modify memcg like this:
>> allocate the memory from the memory block they are describing
>>
>> I am not sure it is OK to do so.
>
> I don't see a reason why not.
I'm not sure, but if we do this, we could bring in a fragment for each
memory block (a memory section, 128MB, right?). Is this a problem when
we use large page (such as 1GB page) ?
Even if not, will these fragments make any bad effects ?
Thank. :)
>
> You would have to tweak a bit the lookup function for page_cgroup, but
> assuming you will always have the pfns and limits, it should be easy to do.
>
> I think the only tricky part is that today we have a single
> node_page_cgroup, and we would of course have to have one per memory
> block. My assumption is that the number of memory blocks is limited and
> likely not very big. So even a static array would do.
>
> Kamezawa, do you have any input in here?
>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Glauber Costa <glommer@parallels.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
akpm@linux-foundation.org, rientjes@google.com, liuj97@gmail.com,
len.brown@intel.com, benh@kernel.crashing.org, paulus@samba.org,
cl@linux.com, minchan.kim@gmail.com,
kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
wujianguo@huawei.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
sparclinux@vger.kernel.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
Date: Thu, 10 Jan 2013 01:38:10 +0000 [thread overview]
Message-ID: <50EE1B82.4090601@cn.fujitsu.com> (raw)
In-Reply-To: <50ED8834.1090804@parallels.com>
Hi Glauber,
On 01/09/2013 11:09 PM, Glauber Costa wrote:
>>
>> We try to make all page_cgroup allocations local to the node they are describing
>> now. If the memory is the first memory onlined in this node, we will allocate
>> it from the other node.
>>
>> For example, node1 has 4 memory blocks: 8-11, and we online it from 8 to 11
>> 1. memory block 8, page_cgroup allocations are in the other nodes
>> 2. memory block 9, page_cgroup allocations are in memory block 8
>>
>> So we should offline memory block 9 first. But we don't know in which order
>> the user online the memory block.
>>
>> I think we can modify memcg like this:
>> allocate the memory from the memory block they are describing
>>
>> I am not sure it is OK to do so.
>
> I don't see a reason why not.
I'm not sure, but if we do this, we could bring in a fragment for each
memory block (a memory section, 128MB, right?). Is this a problem when
we use large page (such as 1GB page) ?
Even if not, will these fragments make any bad effects ?
Thank. :)
>
> You would have to tweak a bit the lookup function for page_cgroup, but
> assuming you will always have the pfns and limits, it should be easy to do.
>
> I think the only tricky part is that today we have a single
> node_page_cgroup, and we would of course have to have one per memory
> block. My assumption is that the number of memory blocks is limited and
> likely not very big. So even a static array would do.
>
> Kamezawa, do you have any input in here?
>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Glauber Costa <glommer@parallels.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,
sparclinux@vger.kernel.org, cl@linux.com,
linux-s390@vger.kernel.org, x86@kernel.org,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
linfeng@cn.fujitsu.com, mgorman@suse.de,
kosaki.motohiro@jp.fujitsu.com, rientjes@google.com,
liuj97@gmail.com, len.brown@intel.com,
Wen Congyang <wency@cn.fujitsu.com>,
cmetcalf@tilera.com, wujianguo@huawei.com, yinghai@kernel.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org,
minchan.kim@gmail.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
Date: Thu, 10 Jan 2013 09:38:10 +0800 [thread overview]
Message-ID: <50EE1B82.4090601@cn.fujitsu.com> (raw)
In-Reply-To: <50ED8834.1090804@parallels.com>
Hi Glauber,
On 01/09/2013 11:09 PM, Glauber Costa wrote:
>>
>> We try to make all page_cgroup allocations local to the node they are describing
>> now. If the memory is the first memory onlined in this node, we will allocate
>> it from the other node.
>>
>> For example, node1 has 4 memory blocks: 8-11, and we online it from 8 to 11
>> 1. memory block 8, page_cgroup allocations are in the other nodes
>> 2. memory block 9, page_cgroup allocations are in memory block 8
>>
>> So we should offline memory block 9 first. But we don't know in which order
>> the user online the memory block.
>>
>> I think we can modify memcg like this:
>> allocate the memory from the memory block they are describing
>>
>> I am not sure it is OK to do so.
>
> I don't see a reason why not.
I'm not sure, but if we do this, we could bring in a fragment for each
memory block (a memory section, 128MB, right?). Is this a problem when
we use large page (such as 1GB page) ?
Even if not, will these fragments make any bad effects ?
Thank. :)
>
> You would have to tweak a bit the lookup function for page_cgroup, but
> assuming you will always have the pfns and limits, it should be easy to do.
>
> I think the only tricky part is that today we have a single
> node_page_cgroup, and we would of course have to have one per memory
> block. My assumption is that the number of memory blocks is limited and
> likely not very big. So even a static array would do.
>
> Kamezawa, do you have any input in here?
>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Glauber Costa <glommer@parallels.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
akpm@linux-foundation.org, rientjes@google.com, liuj97@gmail.com,
len.brown@intel.com, benh@kernel.crashing.org, paulus@samba.org,
cl@linux.com, minchan.kim@gmail.com,
kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
wujianguo@huawei.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
sparclinux@vger.kernel.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
Date: Thu, 10 Jan 2013 09:38:10 +0800 [thread overview]
Message-ID: <50EE1B82.4090601@cn.fujitsu.com> (raw)
In-Reply-To: <50ED8834.1090804@parallels.com>
Hi Glauber,
On 01/09/2013 11:09 PM, Glauber Costa wrote:
>>
>> We try to make all page_cgroup allocations local to the node they are describing
>> now. If the memory is the first memory onlined in this node, we will allocate
>> it from the other node.
>>
>> For example, node1 has 4 memory blocks: 8-11, and we online it from 8 to 11
>> 1. memory block 8, page_cgroup allocations are in the other nodes
>> 2. memory block 9, page_cgroup allocations are in memory block 8
>>
>> So we should offline memory block 9 first. But we don't know in which order
>> the user online the memory block.
>>
>> I think we can modify memcg like this:
>> allocate the memory from the memory block they are describing
>>
>> I am not sure it is OK to do so.
>
> I don't see a reason why not.
I'm not sure, but if we do this, we could bring in a fragment for each
memory block (a memory section, 128MB, right?). Is this a problem when
we use large page (such as 1GB page) ?
Even if not, will these fragments make any bad effects ?
Thank. :)
>
> You would have to tweak a bit the lookup function for page_cgroup, but
> assuming you will always have the pfns and limits, it should be easy to do.
>
> I think the only tricky part is that today we have a single
> node_page_cgroup, and we would of course have to have one per memory
> block. My assumption is that the number of memory blocks is limited and
> likely not very big. So even a static array would do.
>
> Kamezawa, do you have any input in here?
>
--
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-01-10 2:00 UTC|newest]
Thread overview: 194+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-24 12:09 [PATCH v5 00/14] memory-hotplug: hot-remove physical memory Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-25 8:35 ` Glauber Costa
2012-12-25 8:35 ` Glauber Costa
2012-12-25 8:35 ` Glauber Costa
2012-12-25 8:35 ` Glauber Costa
2012-12-25 8:35 ` Glauber Costa
2012-12-30 5:58 ` Wen Congyang
2012-12-30 5:58 ` Wen Congyang
2012-12-30 5:58 ` Wen Congyang
2012-12-30 5:58 ` Wen Congyang
2013-01-09 15:09 ` Glauber Costa
2013-01-09 15:09 ` Glauber Costa
2013-01-09 15:09 ` Glauber Costa
2013-01-09 15:09 ` Glauber Costa
2013-01-09 15:09 ` Glauber Costa
2013-01-10 1:38 ` Tang Chen [this message]
2013-01-10 1:38 ` Tang Chen
2013-01-10 1:38 ` Tang Chen
2013-01-10 1:38 ` Tang Chen
2013-02-06 3:07 ` Tang Chen
2013-02-06 3:07 ` Tang Chen
2013-02-06 3:07 ` Tang Chen
2013-02-06 3:07 ` Tang Chen
2013-02-06 9:17 ` Tang Chen
2013-02-06 9:17 ` Tang Chen
2013-02-06 9:17 ` Tang Chen
2013-02-06 9:17 ` Tang Chen
2013-02-06 10:10 ` Tang Chen
2013-02-06 10:10 ` Tang Chen
2013-02-06 10:10 ` Tang Chen
2013-02-06 10:10 ` Tang Chen
2013-02-06 14:24 ` Glauber Costa
2013-02-06 14:24 ` Glauber Costa
2013-02-06 14:24 ` Glauber Costa
2013-02-06 14:24 ` Glauber Costa
2013-02-06 14:24 ` Glauber Costa
2013-02-07 7:56 ` Tang Chen
2013-02-07 7:56 ` Tang Chen
2013-02-07 7:56 ` Tang Chen
2013-02-07 7:56 ` Tang Chen
2012-12-26 3:02 ` Kamezawa Hiroyuki
2012-12-26 3:02 ` Kamezawa Hiroyuki
2012-12-26 3:02 ` Kamezawa Hiroyuki
2012-12-26 3:02 ` Kamezawa Hiroyuki
2012-12-30 5:49 ` Wen Congyang
2012-12-30 5:49 ` Wen Congyang
2012-12-30 5:49 ` Wen Congyang
2012-12-30 5:49 ` Wen Congyang
2012-12-24 12:09 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removing m Tang Chen
2012-12-26 3:10 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Kamezawa Hiroyuki
2012-12-26 3:10 ` Kamezawa Hiroyuki
2012-12-26 3:10 ` Kamezawa Hiroyuki
2012-12-26 3:10 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removi Kamezawa Hiroyuki
2012-12-27 3:10 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Tang Chen
2012-12-27 3:10 ` Tang Chen
2012-12-27 3:10 ` Tang Chen
2012-12-27 3:10 ` [PATCH v5 02/14] memory-hotplug: check whether all memory blocks are offlined or not when removi Tang Chen
2012-12-24 12:09 ` [PATCH v5 03/14] memory-hotplug: remove redundant codes Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-26 3:20 ` Kamezawa Hiroyuki
2012-12-26 3:20 ` Kamezawa Hiroyuki
2012-12-26 3:20 ` Kamezawa Hiroyuki
2012-12-26 3:20 ` Kamezawa Hiroyuki
2012-12-27 3:09 ` Tang Chen
2012-12-27 3:09 ` Tang Chen
2012-12-27 3:09 ` Tang Chen
2012-12-27 3:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 04/14] memory-hotplug: remove /sys/firmware/memmap/X sysfs Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-26 3:30 ` Kamezawa Hiroyuki
2012-12-26 3:30 ` Kamezawa Hiroyuki
2012-12-26 3:30 ` Kamezawa Hiroyuki
2012-12-26 3:30 ` Kamezawa Hiroyuki
2012-12-27 3:09 ` Tang Chen
2012-12-27 3:09 ` Tang Chen
2012-12-27 3:09 ` Tang Chen
2012-12-27 3:09 ` Tang Chen
2013-01-02 14:24 ` Christoph Lameter
2013-01-02 14:24 ` Christoph Lameter
2013-01-02 14:24 ` Christoph Lameter
2013-01-02 14:24 ` Christoph Lameter
2012-12-24 12:09 ` [PATCH v5 05/14] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 05/14] memory-hotplug: introduce new function arch_remove_memory() for removing page table Tang Chen
2012-12-26 3:37 ` [PATCH v5 05/14] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture Kamezawa Hiroyuki
2012-12-26 3:37 ` Kamezawa Hiroyuki
2012-12-26 3:37 ` Kamezawa Hiroyuki
2012-12-26 3:37 ` [PATCH v5 05/14] memory-hotplug: introduce new function arch_remove_memory() for removing page t Kamezawa Hiroyuki
2012-12-24 12:09 ` [PATCH v5 06/14] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-25 8:09 ` Jianguo Wu
2012-12-25 8:09 ` Jianguo Wu
2012-12-25 8:09 ` Jianguo Wu
2012-12-25 8:09 ` Jianguo Wu
2012-12-25 8:09 ` Jianguo Wu
2012-12-26 3:21 ` Tang Chen
2012-12-26 3:21 ` Tang Chen
2012-12-26 3:21 ` Tang Chen
2012-12-26 3:21 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 07/14] memory-hotplug: move pgdat_resize_lock into sparse_remove_one_section() Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-26 3:47 ` Kamezawa Hiroyuki
2012-12-26 3:47 ` Kamezawa Hiroyuki
2012-12-26 3:47 ` Kamezawa Hiroyuki
2012-12-26 3:47 ` Kamezawa Hiroyuki
2012-12-26 6:20 ` Tang Chen
2012-12-26 6:20 ` Tang Chen
2012-12-26 6:20 ` Tang Chen
2012-12-26 6:20 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 08/14] memory-hotplug: Common APIs to support page tables hot-remove Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-25 8:17 ` Jianguo Wu
2012-12-25 8:17 ` Jianguo Wu
2012-12-25 8:17 ` Jianguo Wu
2012-12-25 8:17 ` Jianguo Wu
2012-12-26 2:49 ` Tang Chen
2012-12-26 2:49 ` Tang Chen
2012-12-26 2:49 ` Tang Chen
2012-12-26 2:49 ` Tang Chen
2012-12-26 3:11 ` Tang Chen
2012-12-26 3:11 ` Tang Chen
2012-12-26 3:11 ` Tang Chen
2012-12-26 3:11 ` Tang Chen
2012-12-26 3:19 ` Tang Chen
2012-12-26 3:19 ` Tang Chen
2012-12-26 3:19 ` Tang Chen
2012-12-26 3:19 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 09/14] memory-hotplug: remove page table of x86_64 architecture Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 10/14] memory-hotplug: remove memmap of sparse-vmemmap Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 11/14] memory-hotplug: Integrated __remove_section() of CONFIG_SPARSEMEM_VMEMMAP Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 12/14] memory-hotplug: memory_hotplug: clear zone when removing the memory Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 13/14] memory-hotplug: remove sysfs file of node Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-24 12:09 ` Tang Chen
2012-12-26 3:55 ` Kamezawa Hiroyuki
2012-12-26 3:55 ` Kamezawa Hiroyuki
2012-12-26 3:55 ` Kamezawa Hiroyuki
2012-12-26 3:55 ` Kamezawa Hiroyuki
2012-12-27 12:16 ` Wen Congyang
2012-12-27 12:16 ` Wen Congyang
2012-12-27 12:16 ` Wen Congyang
2012-12-27 12:16 ` Wen Congyang
2012-12-28 0:28 ` Kamezawa Hiroyuki
2012-12-28 0:28 ` Kamezawa Hiroyuki
2012-12-28 0:28 ` Kamezawa Hiroyuki
2012-12-28 0:28 ` Kamezawa Hiroyuki
2012-12-30 5:55 ` Wen Congyang
2012-12-30 6:02 ` Wen Congyang
2012-12-30 6:02 ` Wen Congyang
2012-12-30 6:02 ` Wen Congyang
2012-12-30 5:55 ` Wen Congyang
2012-12-30 5:55 ` Wen Congyang
2013-01-07 5:30 ` Kamezawa Hiroyuki
2013-01-07 5:30 ` Kamezawa Hiroyuki
2013-01-07 5:30 ` Kamezawa Hiroyuki
2013-01-07 5:30 ` Kamezawa Hiroyuki
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=50EE1B82.4090601@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=cmetcalf@tilera.com \
--cc=glommer@parallels.com \
--cc=hpa@zytor.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linfeng@cn.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=liuj97@gmail.com \
--cc=mgorman@suse.de \
--cc=minchan.kim@gmail.com \
--cc=paulus@samba.org \
--cc=rientjes@google.com \
--cc=sparclinux@vger.kernel.org \
--cc=wency@cn.fujitsu.com \
--cc=wujianguo@huawei.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/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.