From: guohanjun@huawei.com (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: Suspicious error for CMA stress test
Date: Thu, 3 Mar 2016 20:49:01 +0800 [thread overview]
Message-ID: <56D832BD.5080305@huawei.com> (raw)
In-Reply-To: <CAAmzW4PUwoVF+F-BpOZUHhH6YHp_Z8VkiUjdBq85vK6AWVkyPg@mail.gmail.com>
On 2016/3/3 15:42, Joonsoo Kim wrote:
> 2016-03-03 10:25 GMT+09:00 Laura Abbott <labbott@redhat.com>:
>> (cc -mm and Joonsoo Kim)
>>
>>
>> On 03/02/2016 05:52 AM, Hanjun Guo wrote:
>>> Hi,
>>>
>>> I came across a suspicious error for CMA stress test:
>>>
>>> Before the test, I got:
>>> -bash-4.3# cat /proc/meminfo | grep Cma
>>> CmaTotal: 204800 kB
>>> CmaFree: 195044 kB
>>>
>>>
>>> After running the test:
>>> -bash-4.3# cat /proc/meminfo | grep Cma
>>> CmaTotal: 204800 kB
>>> CmaFree: 6602584 kB
>>>
>>> So the freed CMA memory is more than total..
>>>
>>> Also the the MemFree is more than mem total:
>>>
>>> -bash-4.3# cat /proc/meminfo
>>> MemTotal: 16342016 kB
>>> MemFree: 22367268 kB
>>> MemAvailable: 22370528 kB
[...]
>>
>> I played with this a bit and can see the same problem. The sanity
>> check of CmaFree < CmaTotal generally triggers in
>> __move_zone_freepage_state in unset_migratetype_isolate.
>> This also seems to be present as far back as v4.0 which was the
>> first version to have the updated accounting from Joonsoo.
>> Were there known limitations with the new freepage accounting,
>> Joonsoo?
> I don't know. I also played with this and looks like there is
> accounting problem, however, for my case, number of free page is slightly less
> than total. I will take a look.
>
> Hanjun, could you tell me your malloc_size? I tested with 1 and it doesn't
> look like your case.
I tested with malloc_size with 2M, and it grows much bigger than 1M, also I
did some other test:
- run with single thread with 100000 times, everything is fine.
- I hack the cam_alloc() and free as below [1] to see if it's lock issue, with
the same test with 100 multi-thread, then I got:
-bash-4.3# cat /proc/meminfo | grep Cma
CmaTotal: 204800 kB
CmaFree: 225112 kB
It only increased about 30M for free, not 6G+ in previous test, although
the problem is not solved, the problem is less serious, is it a synchronization
problem?
Thanks
Hanjun
[1]:
index ea506eb..4447494 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -379,6 +379,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
if (!count)
return NULL;
+ mutex_lock(&cma_mutex);
mask = cma_bitmap_aligned_mask(cma, align);
offset = cma_bitmap_aligned_offset(cma, align);
bitmap_maxno = cma_bitmap_maxno(cma);
@@ -402,17 +403,16 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
mutex_unlock(&cma->lock);
pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
- mutex_lock(&cma_mutex);
ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
- mutex_unlock(&cma_mutex);
if (ret == 0) {
page = pfn_to_page(pfn);
break;
}
cma_clear_bitmap(cma, pfn, count);
- if (ret != -EBUSY)
+ if (ret != -EBUSY) {
break;
+ }
pr_debug("%s(): memory range at %p is busy, retrying\n",
__func__, pfn_to_page(pfn));
@@ -420,6 +420,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
start = bitmap_no + mask + 1;
}
+ mutex_unlock(&cma_mutex);
trace_cma_alloc(pfn, page, count, align);
pr_debug("%s(): returned %p\n", __func__, page);
@@ -445,15 +446,19 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
pr_debug("%s(page %p)\n", __func__, (void *)pages);
+ mutex_lock(&cma_mutex);
pfn = page_to_pfn(pages);
- if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
+ if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count) {
+ mutex_unlock(&cma_mutex);
return false;
+ }
VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
free_contig_range(pfn, count);
cma_clear_bitmap(cma, pfn, count);
+ mutex_unlock(&cma_mutex);
trace_cma_release(pfn, pages, count);
return true;
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <guohanjun@huawei.com>
To: Joonsoo Kim <js1304@gmail.com>, Laura Abbott <labbott@redhat.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sasha Levin <sasha.levin@oracle.com>,
Laura Abbott <lauraa@codeaurora.org>,
qiuxishi <qiuxishi@huawei.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
"thunder.leizhen@huawei.com" <thunder.leizhen@huawei.com>,
dingtinahong <dingtianhong@huawei.com>,
chenjie6@huawei.com, "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Suspicious error for CMA stress test
Date: Thu, 3 Mar 2016 20:49:01 +0800 [thread overview]
Message-ID: <56D832BD.5080305@huawei.com> (raw)
In-Reply-To: <CAAmzW4PUwoVF+F-BpOZUHhH6YHp_Z8VkiUjdBq85vK6AWVkyPg@mail.gmail.com>
On 2016/3/3 15:42, Joonsoo Kim wrote:
> 2016-03-03 10:25 GMT+09:00 Laura Abbott <labbott@redhat.com>:
>> (cc -mm and Joonsoo Kim)
>>
>>
>> On 03/02/2016 05:52 AM, Hanjun Guo wrote:
>>> Hi,
>>>
>>> I came across a suspicious error for CMA stress test:
>>>
>>> Before the test, I got:
>>> -bash-4.3# cat /proc/meminfo | grep Cma
>>> CmaTotal: 204800 kB
>>> CmaFree: 195044 kB
>>>
>>>
>>> After running the test:
>>> -bash-4.3# cat /proc/meminfo | grep Cma
>>> CmaTotal: 204800 kB
>>> CmaFree: 6602584 kB
>>>
>>> So the freed CMA memory is more than total..
>>>
>>> Also the the MemFree is more than mem total:
>>>
>>> -bash-4.3# cat /proc/meminfo
>>> MemTotal: 16342016 kB
>>> MemFree: 22367268 kB
>>> MemAvailable: 22370528 kB
[...]
>>
>> I played with this a bit and can see the same problem. The sanity
>> check of CmaFree < CmaTotal generally triggers in
>> __move_zone_freepage_state in unset_migratetype_isolate.
>> This also seems to be present as far back as v4.0 which was the
>> first version to have the updated accounting from Joonsoo.
>> Were there known limitations with the new freepage accounting,
>> Joonsoo?
> I don't know. I also played with this and looks like there is
> accounting problem, however, for my case, number of free page is slightly less
> than total. I will take a look.
>
> Hanjun, could you tell me your malloc_size? I tested with 1 and it doesn't
> look like your case.
I tested with malloc_size with 2M, and it grows much bigger than 1M, also I
did some other test:
- run with single thread with 100000 times, everything is fine.
- I hack the cam_alloc() and free as below [1] to see if it's lock issue, with
the same test with 100 multi-thread, then I got:
-bash-4.3# cat /proc/meminfo | grep Cma
CmaTotal: 204800 kB
CmaFree: 225112 kB
It only increased about 30M for free, not 6G+ in previous test, although
the problem is not solved, the problem is less serious, is it a synchronization
problem?
Thanks
Hanjun
[1]:
index ea506eb..4447494 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -379,6 +379,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
if (!count)
return NULL;
+ mutex_lock(&cma_mutex);
mask = cma_bitmap_aligned_mask(cma, align);
offset = cma_bitmap_aligned_offset(cma, align);
bitmap_maxno = cma_bitmap_maxno(cma);
@@ -402,17 +403,16 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
mutex_unlock(&cma->lock);
pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
- mutex_lock(&cma_mutex);
ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
- mutex_unlock(&cma_mutex);
if (ret == 0) {
page = pfn_to_page(pfn);
break;
}
cma_clear_bitmap(cma, pfn, count);
- if (ret != -EBUSY)
+ if (ret != -EBUSY) {
break;
+ }
pr_debug("%s(): memory range at %p is busy, retrying\n",
__func__, pfn_to_page(pfn));
@@ -420,6 +420,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
start = bitmap_no + mask + 1;
}
+ mutex_unlock(&cma_mutex);
trace_cma_alloc(pfn, page, count, align);
pr_debug("%s(): returned %p\n", __func__, page);
@@ -445,15 +446,19 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
pr_debug("%s(page %p)\n", __func__, (void *)pages);
+ mutex_lock(&cma_mutex);
pfn = page_to_pfn(pages);
- if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
+ if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count) {
+ mutex_unlock(&cma_mutex);
return false;
+ }
VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
free_contig_range(pfn, count);
cma_clear_bitmap(cma, pfn, count);
+ mutex_unlock(&cma_mutex);
trace_cma_release(pfn, pages, count);
return true;
--
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: Hanjun Guo <guohanjun@huawei.com>
To: Joonsoo Kim <js1304@gmail.com>, Laura Abbott <labbott@redhat.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sasha Levin <sasha.levin@oracle.com>,
Laura Abbott <lauraa@codeaurora.org>,
qiuxishi <qiuxishi@huawei.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
"thunder.leizhen@huawei.com" <thunder.leizhen@huawei.com>,
dingtinahong <dingtianhong@huawei.com>, <chenjie6@huawei.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Suspicious error for CMA stress test
Date: Thu, 3 Mar 2016 20:49:01 +0800 [thread overview]
Message-ID: <56D832BD.5080305@huawei.com> (raw)
In-Reply-To: <CAAmzW4PUwoVF+F-BpOZUHhH6YHp_Z8VkiUjdBq85vK6AWVkyPg@mail.gmail.com>
On 2016/3/3 15:42, Joonsoo Kim wrote:
> 2016-03-03 10:25 GMT+09:00 Laura Abbott <labbott@redhat.com>:
>> (cc -mm and Joonsoo Kim)
>>
>>
>> On 03/02/2016 05:52 AM, Hanjun Guo wrote:
>>> Hi,
>>>
>>> I came across a suspicious error for CMA stress test:
>>>
>>> Before the test, I got:
>>> -bash-4.3# cat /proc/meminfo | grep Cma
>>> CmaTotal: 204800 kB
>>> CmaFree: 195044 kB
>>>
>>>
>>> After running the test:
>>> -bash-4.3# cat /proc/meminfo | grep Cma
>>> CmaTotal: 204800 kB
>>> CmaFree: 6602584 kB
>>>
>>> So the freed CMA memory is more than total..
>>>
>>> Also the the MemFree is more than mem total:
>>>
>>> -bash-4.3# cat /proc/meminfo
>>> MemTotal: 16342016 kB
>>> MemFree: 22367268 kB
>>> MemAvailable: 22370528 kB
[...]
>>
>> I played with this a bit and can see the same problem. The sanity
>> check of CmaFree < CmaTotal generally triggers in
>> __move_zone_freepage_state in unset_migratetype_isolate.
>> This also seems to be present as far back as v4.0 which was the
>> first version to have the updated accounting from Joonsoo.
>> Were there known limitations with the new freepage accounting,
>> Joonsoo?
> I don't know. I also played with this and looks like there is
> accounting problem, however, for my case, number of free page is slightly less
> than total. I will take a look.
>
> Hanjun, could you tell me your malloc_size? I tested with 1 and it doesn't
> look like your case.
I tested with malloc_size with 2M, and it grows much bigger than 1M, also I
did some other test:
- run with single thread with 100000 times, everything is fine.
- I hack the cam_alloc() and free as below [1] to see if it's lock issue, with
the same test with 100 multi-thread, then I got:
-bash-4.3# cat /proc/meminfo | grep Cma
CmaTotal: 204800 kB
CmaFree: 225112 kB
It only increased about 30M for free, not 6G+ in previous test, although
the problem is not solved, the problem is less serious, is it a synchronization
problem?
Thanks
Hanjun
[1]:
index ea506eb..4447494 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -379,6 +379,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
if (!count)
return NULL;
+ mutex_lock(&cma_mutex);
mask = cma_bitmap_aligned_mask(cma, align);
offset = cma_bitmap_aligned_offset(cma, align);
bitmap_maxno = cma_bitmap_maxno(cma);
@@ -402,17 +403,16 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
mutex_unlock(&cma->lock);
pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
- mutex_lock(&cma_mutex);
ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
- mutex_unlock(&cma_mutex);
if (ret == 0) {
page = pfn_to_page(pfn);
break;
}
cma_clear_bitmap(cma, pfn, count);
- if (ret != -EBUSY)
+ if (ret != -EBUSY) {
break;
+ }
pr_debug("%s(): memory range at %p is busy, retrying\n",
__func__, pfn_to_page(pfn));
@@ -420,6 +420,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
start = bitmap_no + mask + 1;
}
+ mutex_unlock(&cma_mutex);
trace_cma_alloc(pfn, page, count, align);
pr_debug("%s(): returned %p\n", __func__, page);
@@ -445,15 +446,19 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
pr_debug("%s(page %p)\n", __func__, (void *)pages);
+ mutex_lock(&cma_mutex);
pfn = page_to_pfn(pages);
- if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
+ if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count) {
+ mutex_unlock(&cma_mutex);
return false;
+ }
VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
free_contig_range(pfn, count);
cma_clear_bitmap(cma, pfn, count);
+ mutex_unlock(&cma_mutex);
trace_cma_release(pfn, pages, count);
return true;
next prev parent reply other threads:[~2016-03-03 12:49 UTC|newest]
Thread overview: 176+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 13:52 Suspicious error for CMA stress test Hanjun Guo
2016-03-02 13:52 ` Hanjun Guo
2016-03-03 1:25 ` Laura Abbott
2016-03-03 1:25 ` Laura Abbott
2016-03-03 1:25 ` Laura Abbott
2016-03-03 6:07 ` Hanjun Guo
2016-03-03 6:07 ` Hanjun Guo
2016-03-03 6:07 ` Hanjun Guo
2016-03-03 7:42 ` Joonsoo Kim
2016-03-03 7:42 ` Joonsoo Kim
2016-03-03 7:42 ` Joonsoo Kim
2016-03-03 7:58 ` Hanjun Guo
2016-03-03 7:58 ` Hanjun Guo
2016-03-03 7:58 ` Hanjun Guo
2016-03-03 12:49 ` Hanjun Guo [this message]
2016-03-03 12:49 ` Hanjun Guo
2016-03-03 12:49 ` Hanjun Guo
2016-03-03 18:52 ` Laura Abbott
2016-03-03 18:52 ` Laura Abbott
2016-03-03 18:52 ` Laura Abbott
2016-03-04 2:09 ` Joonsoo Kim
2016-03-04 2:09 ` Joonsoo Kim
2016-03-04 2:09 ` Joonsoo Kim
2016-03-04 6:09 ` Hanjun Guo
2016-03-04 6:09 ` Hanjun Guo
2016-03-04 6:09 ` Hanjun Guo
2016-03-04 2:02 ` Joonsoo Kim
2016-03-04 2:02 ` Joonsoo Kim
2016-03-04 2:02 ` Joonsoo Kim
2016-03-04 4:32 ` Joonsoo Kim
2016-03-04 4:32 ` Joonsoo Kim
2016-03-04 4:32 ` Joonsoo Kim
2016-03-04 6:05 ` Hanjun Guo
2016-03-04 6:05 ` Hanjun Guo
2016-03-04 6:05 ` Hanjun Guo
2016-03-04 6:38 ` Joonsoo Kim
2016-03-04 6:38 ` Joonsoo Kim
2016-03-04 6:38 ` Joonsoo Kim
2016-03-04 7:35 ` Hanjun Guo
2016-03-04 7:35 ` Hanjun Guo
2016-03-04 7:35 ` Hanjun Guo
2016-03-07 4:34 ` Joonsoo Kim
2016-03-07 4:34 ` Joonsoo Kim
2016-03-07 4:34 ` Joonsoo Kim
2016-03-07 8:16 ` Leizhen (ThunderTown)
2016-03-07 8:16 ` Leizhen (ThunderTown)
2016-03-07 8:16 ` Leizhen (ThunderTown)
2016-03-07 18:42 ` Laura Abbott
2016-03-07 18:42 ` Laura Abbott
2016-03-07 18:42 ` Laura Abbott
2016-03-08 1:54 ` Leizhen (ThunderTown)
2016-03-08 1:54 ` Leizhen (ThunderTown)
2016-03-08 1:54 ` Leizhen (ThunderTown)
2016-03-09 1:23 ` Leizhen (ThunderTown)
2016-03-09 1:23 ` Leizhen (ThunderTown)
2016-03-09 1:23 ` Leizhen (ThunderTown)
2016-03-11 15:00 ` Joonsoo Kim
2016-03-11 15:00 ` Joonsoo Kim
2016-03-11 15:00 ` Joonsoo Kim
2016-03-11 17:07 ` Vlastimil Babka
2016-03-11 17:07 ` Vlastimil Babka
2016-03-11 17:07 ` Vlastimil Babka
2016-03-14 6:49 ` Joonsoo Kim
2016-03-14 6:49 ` Joonsoo Kim
2016-03-14 6:49 ` Joonsoo Kim
2016-03-14 7:06 ` Vlastimil Babka
2016-03-14 7:06 ` Vlastimil Babka
2016-03-14 7:06 ` Vlastimil Babka
2016-03-14 7:18 ` Joonsoo Kim
2016-03-14 7:18 ` Joonsoo Kim
2016-03-14 7:18 ` Joonsoo Kim
2016-03-14 12:30 ` Vlastimil Babka
2016-03-14 12:30 ` Vlastimil Babka
2016-03-14 12:30 ` Vlastimil Babka
2016-03-14 14:10 ` Joonsoo Kim
2016-03-14 14:10 ` Joonsoo Kim
2016-03-14 14:10 ` Joonsoo Kim
2016-03-16 12:03 ` Vlastimil Babka
2016-03-16 12:03 ` Vlastimil Babka
2016-03-16 12:03 ` Vlastimil Babka
2016-03-16 9:44 ` Hanjun Guo
2016-03-16 9:44 ` Hanjun Guo
2016-03-16 9:44 ` Hanjun Guo
2016-03-17 6:54 ` Joonsoo Kim
2016-03-17 6:54 ` Joonsoo Kim
2016-03-17 6:54 ` Joonsoo Kim
2016-03-17 9:24 ` Hanjun Guo
2016-03-17 9:24 ` Hanjun Guo
2016-03-17 9:24 ` Hanjun Guo
2016-03-17 15:31 ` Joonsoo Kim
2016-03-17 15:31 ` Joonsoo Kim
2016-03-17 15:31 ` Joonsoo Kim
2016-03-18 2:03 ` Hanjun Guo
2016-03-18 2:03 ` Hanjun Guo
2016-03-18 2:03 ` Hanjun Guo
2016-03-17 15:43 ` Vlastimil Babka
2016-03-17 15:43 ` Vlastimil Babka
2016-03-17 15:43 ` Vlastimil Babka
2016-03-17 15:52 ` Joonsoo Kim
2016-03-17 15:52 ` Joonsoo Kim
2016-03-17 15:52 ` Joonsoo Kim
2016-03-18 13:32 ` Lucas Stach
2016-03-18 13:32 ` Lucas Stach
2016-03-18 13:32 ` Lucas Stach
2016-03-21 4:42 ` Joonsoo Kim
2016-03-21 4:42 ` Joonsoo Kim
2016-03-21 4:42 ` Joonsoo Kim
2016-03-22 14:56 ` Lucas Stach
2016-03-22 14:56 ` Lucas Stach
2016-03-22 14:56 ` Lucas Stach
2016-03-23 4:42 ` Joonsoo Kim
2016-03-23 4:42 ` Joonsoo Kim
2016-03-23 4:42 ` Joonsoo Kim
2016-03-18 14:10 ` Vlastimil Babka
2016-03-18 14:10 ` Vlastimil Babka
2016-03-18 14:10 ` Vlastimil Babka
2016-03-18 14:42 ` Lucas Stach
2016-03-18 14:42 ` Lucas Stach
2016-03-18 14:42 ` Lucas Stach
2016-03-18 20:58 ` Vlastimil Babka
2016-03-18 20:58 ` Vlastimil Babka
2016-03-18 20:58 ` Vlastimil Babka
2016-03-22 14:47 ` Lucas Stach
2016-03-22 14:47 ` Lucas Stach
2016-03-22 14:47 ` Lucas Stach
2016-03-19 7:24 ` Hanjun Guo
2016-03-19 7:24 ` Hanjun Guo
2016-03-19 7:24 ` Hanjun Guo
2016-03-19 22:11 ` Vlastimil Babka
2016-03-19 22:11 ` Vlastimil Babka
2016-03-19 22:11 ` Vlastimil Babka
2016-03-23 4:44 ` Joonsoo Kim
2016-03-23 4:44 ` Joonsoo Kim
2016-03-23 4:44 ` Joonsoo Kim
2016-03-23 8:26 ` Vlastimil Babka
2016-03-23 8:26 ` Vlastimil Babka
2016-03-23 8:26 ` Vlastimil Babka
2016-03-23 8:32 ` Joonsoo Kim
2016-03-23 8:32 ` Joonsoo Kim
2016-03-23 8:32 ` Joonsoo Kim
2016-03-18 12:29 ` Vlastimil Babka
2016-03-18 12:29 ` Vlastimil Babka
2016-03-18 12:29 ` Vlastimil Babka
2016-03-08 4:03 ` Hanjun Guo
2016-03-08 4:03 ` Hanjun Guo
2016-03-08 4:03 ` Hanjun Guo
2016-03-07 12:59 ` Vlastimil Babka
2016-03-07 12:59 ` Vlastimil Babka
2016-03-07 12:59 ` Vlastimil Babka
2016-03-08 7:48 ` Joonsoo Kim
2016-03-08 7:48 ` Joonsoo Kim
2016-03-08 7:48 ` Joonsoo Kim
2016-03-08 10:45 ` Xishi Qiu
2016-03-08 10:45 ` Xishi Qiu
2016-03-08 10:45 ` Xishi Qiu
2016-03-08 15:36 ` Joonsoo Kim
2016-03-08 15:36 ` Joonsoo Kim
2016-03-08 15:36 ` Joonsoo Kim
2016-03-09 2:18 ` Xishi Qiu
2016-03-09 2:18 ` Xishi Qiu
2016-03-09 2:18 ` Xishi Qiu
2016-03-04 5:33 ` Hanjun Guo
2016-03-04 5:33 ` Hanjun Guo
2016-03-04 5:33 ` Hanjun Guo
2016-03-08 1:42 ` Xishi Qiu
2016-03-08 1:42 ` Xishi Qiu
2016-03-08 1:42 ` Xishi Qiu
2016-03-08 8:09 ` Joonsoo Kim
2016-03-08 8:09 ` Joonsoo Kim
2016-03-08 8:09 ` Joonsoo Kim
2016-03-04 6:59 ` Hanjun Guo
2016-03-04 6:59 ` Hanjun Guo
2016-03-04 6:59 ` Hanjun Guo
2016-03-07 4:40 ` Joonsoo Kim
2016-03-07 4:40 ` Joonsoo Kim
2016-03-07 4:40 ` Joonsoo Kim
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=56D832BD.5080305@huawei.com \
--to=guohanjun@huawei.com \
--cc=linux-arm-kernel@lists.infradead.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.