From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.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, 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
Subject: Re: [RFC v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem
Date: Tue, 4 Sep 2012 18:54:30 +0900 [thread overview]
Message-ID: <5045CFD6.9040408@jp.fujitsu.com> (raw)
In-Reply-To: <50457983.1050304@cn.fujitsu.com>
Hi Wen,
2012/09/04 12:46, Wen Congyang wrote:
> Hi, isimatu-san
>
> At 09/01/2012 05:30 AM, Andrew Morton Wrote:
>> On Tue, 28 Aug 2012 18:00:20 +0800
>> wency@cn.fujitsu.com wrote:
>>
>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> There is a possibility that get_page_bootmem() is called to the same page many
>>> times. So when get_page_bootmem is called to the same page, the function only
>>> increments page->_count.
>>
>> I really don't understand this explanation, even after having looked at
>> the code. Can you please have another attempt at the changelog?
>
> What is the problem that you want to fix? The function get_page_bootmem()
> may be called to the same page more than once, but I don't find any problem
> about current implementation.
The patch is just optimization. The patch does not fix a problems.
As you know, the function may be called many times for the same page.
I think if a page is sets to page_type and Page Private flag and page->private,
the page need not be set the same things again. So we check page_type when
get_page_bootmem() is called. And if the page has been set to them, the page
is only incremented page->_count.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>>
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
>>> static void get_page_bootmem(unsigned long info, struct page *page,
>>> unsigned long type)
>>> {
>>> - page->lru.next = (struct list_head *) type;
>>> - SetPagePrivate(page);
>>> - set_page_private(page, info);
>>> - atomic_inc(&page->_count);
>>> + unsigned long page_type;
>>> +
>>> + page_type = (unsigned long) page->lru.next;
>>> + if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
>>> + page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
>>> + page->lru.next = (struct list_head *) type;
>>> + SetPagePrivate(page);
>>> + set_page_private(page, info);
>>> + atomic_inc(&page->_count);
>>> + } else
>>> + atomic_inc(&page->_count);
>>> }
>>
>> And a code comment which explains what is going on would be good. As
>> is always the case ;)
>>
>>
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.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, 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
Subject: Re: [RFC v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem
Date: Tue, 04 Sep 2012 09:54:30 +0000 [thread overview]
Message-ID: <5045CFD6.9040408@jp.fujitsu.com> (raw)
In-Reply-To: <50457983.1050304@cn.fujitsu.com>
Hi Wen,
2012/09/04 12:46, Wen Congyang wrote:
> Hi, isimatu-san
>
> At 09/01/2012 05:30 AM, Andrew Morton Wrote:
>> On Tue, 28 Aug 2012 18:00:20 +0800
>> wency@cn.fujitsu.com wrote:
>>
>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> There is a possibility that get_page_bootmem() is called to the same page many
>>> times. So when get_page_bootmem is called to the same page, the function only
>>> increments page->_count.
>>
>> I really don't understand this explanation, even after having looked at
>> the code. Can you please have another attempt at the changelog?
>
> What is the problem that you want to fix? The function get_page_bootmem()
> may be called to the same page more than once, but I don't find any problem
> about current implementation.
The patch is just optimization. The patch does not fix a problems.
As you know, the function may be called many times for the same page.
I think if a page is sets to page_type and Page Private flag and page->private,
the page need not be set the same things again. So we check page_type when
get_page_bootmem() is called. And if the page has been set to them, the page
is only incremented page->_count.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>>
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
>>> static void get_page_bootmem(unsigned long info, struct page *page,
>>> unsigned long type)
>>> {
>>> - page->lru.next = (struct list_head *) type;
>>> - SetPagePrivate(page);
>>> - set_page_private(page, info);
>>> - atomic_inc(&page->_count);
>>> + unsigned long page_type;
>>> +
>>> + page_type = (unsigned long) page->lru.next;
>>> + if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
>>> + page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
>>> + page->lru.next = (struct list_head *) type;
>>> + SetPagePrivate(page);
>>> + set_page_private(page, info);
>>> + atomic_inc(&page->_count);
>>> + } else
>>> + atomic_inc(&page->_count);
>>> }
>>
>> And a code comment which explains what is going on would be good. As
>> is always the case ;)
>>
>>
>
WARNING: multiple messages have this Message-ID (diff)
From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org,
len.brown@intel.com, linux-acpi@vger.kernel.org,
linux-sh@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, cmetcalf@tilera.com,
linux-mm@kvack.org, paulus@samba.org, minchan.kim@gmail.com,
kosaki.motohiro@jp.fujitsu.com, rientjes@google.com,
sparclinux@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org, cl@linux.com, liuj97@gmail.com
Subject: Re: [RFC v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem
Date: Tue, 4 Sep 2012 18:54:30 +0900 [thread overview]
Message-ID: <5045CFD6.9040408@jp.fujitsu.com> (raw)
In-Reply-To: <50457983.1050304@cn.fujitsu.com>
Hi Wen,
2012/09/04 12:46, Wen Congyang wrote:
> Hi, isimatu-san
>
> At 09/01/2012 05:30 AM, Andrew Morton Wrote:
>> On Tue, 28 Aug 2012 18:00:20 +0800
>> wency@cn.fujitsu.com wrote:
>>
>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> There is a possibility that get_page_bootmem() is called to the same page many
>>> times. So when get_page_bootmem is called to the same page, the function only
>>> increments page->_count.
>>
>> I really don't understand this explanation, even after having looked at
>> the code. Can you please have another attempt at the changelog?
>
> What is the problem that you want to fix? The function get_page_bootmem()
> may be called to the same page more than once, but I don't find any problem
> about current implementation.
The patch is just optimization. The patch does not fix a problems.
As you know, the function may be called many times for the same page.
I think if a page is sets to page_type and Page Private flag and page->private,
the page need not be set the same things again. So we check page_type when
get_page_bootmem() is called. And if the page has been set to them, the page
is only incremented page->_count.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>>
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
>>> static void get_page_bootmem(unsigned long info, struct page *page,
>>> unsigned long type)
>>> {
>>> - page->lru.next = (struct list_head *) type;
>>> - SetPagePrivate(page);
>>> - set_page_private(page, info);
>>> - atomic_inc(&page->_count);
>>> + unsigned long page_type;
>>> +
>>> + page_type = (unsigned long) page->lru.next;
>>> + if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
>>> + page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
>>> + page->lru.next = (struct list_head *) type;
>>> + SetPagePrivate(page);
>>> + set_page_private(page, info);
>>> + atomic_inc(&page->_count);
>>> + } else
>>> + atomic_inc(&page->_count);
>>> }
>>
>> And a code comment which explains what is going on would be good. As
>> is always the case ;)
>>
>>
>
WARNING: multiple messages have this Message-ID (diff)
From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.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>, <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>
Subject: Re: [RFC v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem
Date: Tue, 4 Sep 2012 18:54:30 +0900 [thread overview]
Message-ID: <5045CFD6.9040408@jp.fujitsu.com> (raw)
In-Reply-To: <50457983.1050304@cn.fujitsu.com>
Hi Wen,
2012/09/04 12:46, Wen Congyang wrote:
> Hi, isimatu-san
>
> At 09/01/2012 05:30 AM, Andrew Morton Wrote:
>> On Tue, 28 Aug 2012 18:00:20 +0800
>> wency@cn.fujitsu.com wrote:
>>
>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> There is a possibility that get_page_bootmem() is called to the same page many
>>> times. So when get_page_bootmem is called to the same page, the function only
>>> increments page->_count.
>>
>> I really don't understand this explanation, even after having looked at
>> the code. Can you please have another attempt at the changelog?
>
> What is the problem that you want to fix? The function get_page_bootmem()
> may be called to the same page more than once, but I don't find any problem
> about current implementation.
The patch is just optimization. The patch does not fix a problems.
As you know, the function may be called many times for the same page.
I think if a page is sets to page_type and Page Private flag and page->private,
the page need not be set the same things again. So we check page_type when
get_page_bootmem() is called. And if the page has been set to them, the page
is only incremented page->_count.
Thanks,
Yasuaki Ishimatsu
>
> Thanks
> Wen Congyang
>
>>
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
>>> static void get_page_bootmem(unsigned long info, struct page *page,
>>> unsigned long type)
>>> {
>>> - page->lru.next = (struct list_head *) type;
>>> - SetPagePrivate(page);
>>> - set_page_private(page, info);
>>> - atomic_inc(&page->_count);
>>> + unsigned long page_type;
>>> +
>>> + page_type = (unsigned long) page->lru.next;
>>> + if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
>>> + page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
>>> + page->lru.next = (struct list_head *) type;
>>> + SetPagePrivate(page);
>>> + set_page_private(page, info);
>>> + atomic_inc(&page->_count);
>>> + } else
>>> + atomic_inc(&page->_count);
>>> }
>>
>> And a code comment which explains what is going on would be good. As
>> is always the case ;)
>>
>>
>
next prev parent reply other threads:[~2012-09-04 9:54 UTC|newest]
Thread overview: 177+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 10:00 [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 01/20] memory-hotplug: rename remove_memory() to offline_memory()/offline_pages() wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 02/20] memory-hotplug: implement offline_memory() wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 03/20] memory-hotplug: store the node id in acpi_memory_device wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 04/20] memory-hotplug: offline and remove memory when removing the memory device wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-31 20:55 ` Andrew Morton
2012-08-31 20:55 ` Andrew Morton
2012-08-31 20:55 ` Andrew Morton
2012-08-31 20:55 ` Andrew Morton
2012-09-03 1:30 ` Wen Congyang
2012-09-03 1:30 ` Wen Congyang
2012-09-03 1:30 ` Wen Congyang
2012-09-03 1:30 ` Wen Congyang
2012-08-28 10:00 ` [RFC v8 PATCH 05/20] memory-hotplug: check whether memory is present or not wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 06/20] memory-hotplug: export the function acpi_bus_remove() wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 07/20] memory-hotplug: call acpi_bus_remove() to remove memory device wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-31 21:06 ` Andrew Morton
2012-08-31 21:06 ` Andrew Morton
2012-08-31 21:06 ` Andrew Morton
2012-08-31 21:06 ` Andrew Morton
2012-09-03 5:51 ` Wen Congyang
2012-09-03 5:51 ` Wen Congyang
2012-09-03 5:51 ` Wen Congyang
2012-09-03 5:51 ` Wen Congyang
2012-09-04 23:16 ` Andrew Morton
2012-09-04 23:16 ` Andrew Morton
2012-09-04 23:16 ` Andrew Morton
2012-09-04 23:16 ` Andrew Morton
2012-09-05 1:41 ` Wen Congyang
2012-09-05 1:41 ` Wen Congyang
2012-09-05 1:41 ` Wen Congyang
2012-09-05 1:41 ` Wen Congyang
2012-09-03 7:31 ` Wen Congyang
2012-09-03 7:31 ` Wen Congyang
2012-09-03 7:31 ` Wen Congyang
2012-09-03 7:31 ` Wen Congyang
2012-08-28 10:00 ` [RFC v8 PATCH 09/20] memory-hotplug: does not release memory region in PAGES_PER_SECTION chunks wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 10/20] memory-hotplug: add memory_block_release wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 11/20] memory-hotplug: remove_memory calls __remove_pages wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 12/20] memory-hotplug: introduce new function arch_remove_memory() wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-31 21:30 ` Andrew Morton
2012-08-31 21:30 ` Andrew Morton
2012-08-31 21:30 ` Andrew Morton
2012-08-31 21:30 ` Andrew Morton
2012-09-04 3:46 ` Wen Congyang
2012-09-04 3:46 ` Wen Congyang
2012-09-04 3:46 ` Wen Congyang
2012-09-04 3:46 ` Wen Congyang
2012-09-04 9:54 ` Yasuaki Ishimatsu [this message]
2012-09-04 9:54 ` Yasuaki Ishimatsu
2012-09-04 9:54 ` Yasuaki Ishimatsu
2012-09-04 9:54 ` Yasuaki Ishimatsu
2012-08-28 10:00 ` [RFC v8 PATCH 14/20] memory-hotplug: move register_page_bootmem_info_node and put_page_bootmem for sparse-vmemmap wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 14/20] memory-hotplug: move register_page_bootmem_info_node and put_page_bootmem for s wency
2012-08-28 10:00 ` [RFC v8 PATCH 15/20] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 16/20] memory-hotplug: free memmap " wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 17/20] memory_hotplug: clear zone when the memory is removed wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 18/20] memory-hotplug: add node_device_release wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 19/20] memory-hotplug: remove sysfs file of node wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 20/20] memory-hotplug: clear hwpoisoned flag when onlining pages wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-31 20:49 ` [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory Andrew Morton
2012-08-31 20:49 ` Andrew Morton
2012-08-31 20:49 ` Andrew Morton
2012-08-31 20:49 ` Andrew Morton
2012-09-10 1:46 ` Yasuaki Ishimatsu
2012-09-10 1:46 ` Yasuaki Ishimatsu
2012-09-10 1:46 ` Yasuaki Ishimatsu
2012-09-10 1:46 ` Yasuaki Ishimatsu
2012-09-10 1:56 ` Wen Congyang
2012-09-10 2:01 ` Wen Congyang
2012-09-10 2:01 ` Wen Congyang
2012-09-10 2:01 ` Wen Congyang
2012-09-10 1:56 ` Wen Congyang
2012-09-10 13:52 ` Vasilis Liaskovitis
2012-09-10 13:52 ` Vasilis Liaskovitis
2012-09-10 13:52 ` Vasilis Liaskovitis
2012-09-10 13:52 ` Vasilis Liaskovitis
2012-09-11 0:27 ` Jerry
2012-09-11 0:27 ` Jerry
2012-09-11 1:23 ` Minchan Kim
2012-09-11 1:23 ` Minchan Kim
2012-09-11 1:23 ` Minchan Kim
2012-09-11 1:23 ` Minchan Kim
2012-09-11 5:18 ` Jerry
2012-09-11 5:18 ` Jerry
2012-09-11 5:39 ` Wen Congyang
2012-09-11 5:39 ` Wen Congyang
2012-09-11 5:39 ` Wen Congyang
2012-09-11 5:39 ` Wen Congyang
2012-09-12 6:17 ` Minchan Kim
2012-09-12 6:17 ` Minchan Kim
2012-09-12 6:17 ` Minchan Kim
2012-09-12 6:17 ` Minchan Kim
2012-09-11 1:25 ` Wen Congyang
2012-09-11 1:25 ` Wen Congyang
2012-09-11 1:25 ` Wen Congyang
2012-09-11 1:25 ` Wen Congyang
2012-09-12 5:20 ` Wen Congyang
2012-09-12 5:20 ` Wen Congyang
2012-09-12 5:20 ` Wen Congyang
2012-09-12 5:20 ` Wen Congyang
2012-09-12 17:18 ` Vasilis Liaskovitis
2012-09-12 17:18 ` Vasilis Liaskovitis
2012-09-12 17:18 ` Vasilis Liaskovitis
2012-09-12 17:18 ` Vasilis Liaskovitis
2012-09-18 9:39 ` Wen Congyang
2012-09-18 9:39 ` Wen Congyang
2012-09-18 9:39 ` Wen Congyang
2012-09-18 9:39 ` Wen Congyang
2012-09-19 17:02 ` Vasilis Liaskovitis
2012-09-19 17:02 ` Vasilis Liaskovitis
2012-09-19 17:02 ` Vasilis Liaskovitis
2012-09-19 17:02 ` Vasilis Liaskovitis
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=5045CFD6.9040408@jp.fujitsu.com \
--to=isimatu.yasuaki@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=cmetcalf@tilera.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=len.brown@intel.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=minchan.kim@gmail.com \
--cc=paulus@samba.org \
--cc=rientjes@google.com \
--cc=sparclinux@vger.kernel.org \
--cc=wency@cn.fujitsu.com \
--cc=x86@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.