From: vbabka@suse.cz (Vlastimil Babka)
To: linux-arm-kernel@lists.infradead.org
Subject: Suspicious error for CMA stress test
Date: Mon, 14 Mar 2016 08:06:16 +0100 [thread overview]
Message-ID: <56E662E8.700@suse.cz> (raw)
In-Reply-To: <20160314064925.GA27587@js1304-P5Q-DELUXE>
On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
>> On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
>>
>> How about something like this? Just and idea, probably buggy (off-by-one etc.).
>> Should keep away cost from <pageblock_order iterations@the expense of the
>> relatively fewer >pageblock_order iterations.
>
> Hmm... I tested this and found that it's code size is a little bit
> larger than mine. I'm not sure why this happens exactly but I guess it would be
> related to compiler optimization. In this case, I'm in favor of my
> implementation because it looks like well abstraction. It adds one
> unlikely branch to the merge loop but compiler would optimize it to
> check it once.
I would be surprised if compiler optimized that to check it once, as
order increases with each loop iteration. But maybe it's smart enough to
do something like I did by hand? Guess I'll check the disassembly.
>
> Thanks.
>
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index ff1e3cbc8956..b8005a07b2a1 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -685,21 +685,13 @@ static inline void __free_one_page(struct page *page,
>> unsigned long combined_idx;
>> unsigned long uninitialized_var(buddy_idx);
>> struct page *buddy;
>> - unsigned int max_order = MAX_ORDER;
>> + unsigned int max_order = pageblock_order + 1;
>>
>> VM_BUG_ON(!zone_is_initialized(zone));
>> VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);
>>
>> VM_BUG_ON(migratetype == -1);
>> - if (is_migrate_isolate(migratetype)) {
>> - /*
>> - * We restrict max order of merging to prevent merge
>> - * between freepages on isolate pageblock and normal
>> - * pageblock. Without this, pageblock isolation
>> - * could cause incorrect freepage accounting.
>> - */
>> - max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
>> - } else {
>> + if (likely(!is_migrate_isolate(migratetype))) {
>> __mod_zone_freepage_state(zone, 1 << order, migratetype);
>> }
>>
>> @@ -708,11 +700,12 @@ static inline void __free_one_page(struct page *page,
>> VM_BUG_ON_PAGE(page_idx & ((1 << order) - 1), page);
>> VM_BUG_ON_PAGE(bad_range(zone, page), page);
>>
>> +continue_merging:
>> while (order < max_order - 1) {
>> buddy_idx = __find_buddy_index(page_idx, order);
>> buddy = page + (buddy_idx - page_idx);
>> if (!page_is_buddy(page, buddy, order))
>> - break;
>> + goto done_merging;
>> /*
>> * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page,
>> * merge with it and move up one order.
>> @@ -729,6 +722,26 @@ static inline void __free_one_page(struct page *page,
>> page_idx = combined_idx;
>> order++;
>> }
>> + if (max_order < MAX_ORDER) {
>> + if (IS_ENABLED(CONFIG_CMA) &&
>> + unlikely(has_isolate_pageblock(zone))) {
>> +
>> + int buddy_mt;
>> +
>> + buddy_idx = __find_buddy_index(page_idx, order);
>> + buddy = page + (buddy_idx - page_idx);
>> + buddy_mt = get_pageblock_migratetype(buddy);
>> +
>> + if (migratetype != buddy_mt &&
>> + (is_migrate_isolate(migratetype) ||
>> + is_migrate_isolate(buddy_mt)))
>> + goto done_merging;
>> + }
>> + max_order++;
>> + goto continue_merging;
>> + }
>> +
>> +done_merging:
>> set_page_order(page, order);
>>
>> /*
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo at kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
Laura Abbott <labbott@redhat.com>,
Hanjun Guo <guohanjun@huawei.com>,
"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>,
dingtinahong <dingtianhong@huawei.com>,
chenjie6@huawei.com, "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Suspicious error for CMA stress test
Date: Mon, 14 Mar 2016 08:06:16 +0100 [thread overview]
Message-ID: <56E662E8.700@suse.cz> (raw)
In-Reply-To: <20160314064925.GA27587@js1304-P5Q-DELUXE>
On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
>> On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
>>
>> How about something like this? Just and idea, probably buggy (off-by-one etc.).
>> Should keep away cost from <pageblock_order iterations at the expense of the
>> relatively fewer >pageblock_order iterations.
>
> Hmm... I tested this and found that it's code size is a little bit
> larger than mine. I'm not sure why this happens exactly but I guess it would be
> related to compiler optimization. In this case, I'm in favor of my
> implementation because it looks like well abstraction. It adds one
> unlikely branch to the merge loop but compiler would optimize it to
> check it once.
I would be surprised if compiler optimized that to check it once, as
order increases with each loop iteration. But maybe it's smart enough to
do something like I did by hand? Guess I'll check the disassembly.
>
> Thanks.
>
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index ff1e3cbc8956..b8005a07b2a1 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -685,21 +685,13 @@ static inline void __free_one_page(struct page *page,
>> unsigned long combined_idx;
>> unsigned long uninitialized_var(buddy_idx);
>> struct page *buddy;
>> - unsigned int max_order = MAX_ORDER;
>> + unsigned int max_order = pageblock_order + 1;
>>
>> VM_BUG_ON(!zone_is_initialized(zone));
>> VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);
>>
>> VM_BUG_ON(migratetype == -1);
>> - if (is_migrate_isolate(migratetype)) {
>> - /*
>> - * We restrict max order of merging to prevent merge
>> - * between freepages on isolate pageblock and normal
>> - * pageblock. Without this, pageblock isolation
>> - * could cause incorrect freepage accounting.
>> - */
>> - max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
>> - } else {
>> + if (likely(!is_migrate_isolate(migratetype))) {
>> __mod_zone_freepage_state(zone, 1 << order, migratetype);
>> }
>>
>> @@ -708,11 +700,12 @@ static inline void __free_one_page(struct page *page,
>> VM_BUG_ON_PAGE(page_idx & ((1 << order) - 1), page);
>> VM_BUG_ON_PAGE(bad_range(zone, page), page);
>>
>> +continue_merging:
>> while (order < max_order - 1) {
>> buddy_idx = __find_buddy_index(page_idx, order);
>> buddy = page + (buddy_idx - page_idx);
>> if (!page_is_buddy(page, buddy, order))
>> - break;
>> + goto done_merging;
>> /*
>> * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page,
>> * merge with it and move up one order.
>> @@ -729,6 +722,26 @@ static inline void __free_one_page(struct page *page,
>> page_idx = combined_idx;
>> order++;
>> }
>> + if (max_order < MAX_ORDER) {
>> + if (IS_ENABLED(CONFIG_CMA) &&
>> + unlikely(has_isolate_pageblock(zone))) {
>> +
>> + int buddy_mt;
>> +
>> + buddy_idx = __find_buddy_index(page_idx, order);
>> + buddy = page + (buddy_idx - page_idx);
>> + buddy_mt = get_pageblock_migratetype(buddy);
>> +
>> + if (migratetype != buddy_mt &&
>> + (is_migrate_isolate(migratetype) ||
>> + is_migrate_isolate(buddy_mt)))
>> + goto done_merging;
>> + }
>> + max_order++;
>> + goto continue_merging;
>> + }
>> +
>> +done_merging:
>> set_page_order(page, order);
>>
>> /*
>>
>> --
>> 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>
>
> --
> 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>
>
--
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: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
Laura Abbott <labbott@redhat.com>,
Hanjun Guo <guohanjun@huawei.com>,
"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>,
dingtinahong <dingtianhong@huawei.com>,
chenjie6@huawei.com, "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Suspicious error for CMA stress test
Date: Mon, 14 Mar 2016 08:06:16 +0100 [thread overview]
Message-ID: <56E662E8.700@suse.cz> (raw)
In-Reply-To: <20160314064925.GA27587@js1304-P5Q-DELUXE>
On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
>> On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
>>
>> How about something like this? Just and idea, probably buggy (off-by-one etc.).
>> Should keep away cost from <pageblock_order iterations at the expense of the
>> relatively fewer >pageblock_order iterations.
>
> Hmm... I tested this and found that it's code size is a little bit
> larger than mine. I'm not sure why this happens exactly but I guess it would be
> related to compiler optimization. In this case, I'm in favor of my
> implementation because it looks like well abstraction. It adds one
> unlikely branch to the merge loop but compiler would optimize it to
> check it once.
I would be surprised if compiler optimized that to check it once, as
order increases with each loop iteration. But maybe it's smart enough to
do something like I did by hand? Guess I'll check the disassembly.
>
> Thanks.
>
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index ff1e3cbc8956..b8005a07b2a1 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -685,21 +685,13 @@ static inline void __free_one_page(struct page *page,
>> unsigned long combined_idx;
>> unsigned long uninitialized_var(buddy_idx);
>> struct page *buddy;
>> - unsigned int max_order = MAX_ORDER;
>> + unsigned int max_order = pageblock_order + 1;
>>
>> VM_BUG_ON(!zone_is_initialized(zone));
>> VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);
>>
>> VM_BUG_ON(migratetype == -1);
>> - if (is_migrate_isolate(migratetype)) {
>> - /*
>> - * We restrict max order of merging to prevent merge
>> - * between freepages on isolate pageblock and normal
>> - * pageblock. Without this, pageblock isolation
>> - * could cause incorrect freepage accounting.
>> - */
>> - max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
>> - } else {
>> + if (likely(!is_migrate_isolate(migratetype))) {
>> __mod_zone_freepage_state(zone, 1 << order, migratetype);
>> }
>>
>> @@ -708,11 +700,12 @@ static inline void __free_one_page(struct page *page,
>> VM_BUG_ON_PAGE(page_idx & ((1 << order) - 1), page);
>> VM_BUG_ON_PAGE(bad_range(zone, page), page);
>>
>> +continue_merging:
>> while (order < max_order - 1) {
>> buddy_idx = __find_buddy_index(page_idx, order);
>> buddy = page + (buddy_idx - page_idx);
>> if (!page_is_buddy(page, buddy, order))
>> - break;
>> + goto done_merging;
>> /*
>> * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page,
>> * merge with it and move up one order.
>> @@ -729,6 +722,26 @@ static inline void __free_one_page(struct page *page,
>> page_idx = combined_idx;
>> order++;
>> }
>> + if (max_order < MAX_ORDER) {
>> + if (IS_ENABLED(CONFIG_CMA) &&
>> + unlikely(has_isolate_pageblock(zone))) {
>> +
>> + int buddy_mt;
>> +
>> + buddy_idx = __find_buddy_index(page_idx, order);
>> + buddy = page + (buddy_idx - page_idx);
>> + buddy_mt = get_pageblock_migratetype(buddy);
>> +
>> + if (migratetype != buddy_mt &&
>> + (is_migrate_isolate(migratetype) ||
>> + is_migrate_isolate(buddy_mt)))
>> + goto done_merging;
>> + }
>> + max_order++;
>> + goto continue_merging;
>> + }
>> +
>> +done_merging:
>> set_page_order(page, order);
>>
>> /*
>>
>> --
>> 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>
>
> --
> 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:[~2016-03-14 7:06 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
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 [this message]
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=56E662E8.700@suse.cz \
--to=vbabka@suse.cz \
--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.