Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1359957
| From | Joonsoo Kim <js1304@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Suspicious error for CMA stress test |
| Date | 2016-03-17 16:40 +0100 |
| Message-ID | <rdIbM-Jr-11@gated-at.bofh.it> (permalink) |
| References | (7 earlier) <rcuNz-ve-3@gated-at.bofh.it> <rcuXf-yJ-1@gated-at.bofh.it> <rdgfv-7bg-1@gated-at.bofh.it> <rdA4y-3K4-3@gated-at.bofh.it> <rdCpJ-5uU-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
2016-03-17 18:24 GMT+09:00 Hanjun Guo <guohanjun@huawei.com>:
> On 2016/3/17 14:54, Joonsoo Kim wrote:
>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:
>>> On 2016/3/14 15:18, Joonsoo Kim wrote:
>>>> On Mon, Mar 14, 2016 at 08:06:16AM +0100, Vlastimil Babka wrote:
>>>>> 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.
>>>> Okay. I used following slightly optimized version and I need to
>>>> add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
>>>> to yours. Please consider it, too.
>>> Hmm, this one is not work, I still can see the bug is there after applying
>>> this patch, did I miss something?
>> I may find that there is a bug which was introduced by me some time
>> ago. Could you test following change in __free_one_page() on top of
>> Vlastimil's patch?
>>
>> -page_idx = pfn & ((1 << max_order) - 1);
>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
>
> I tested Vlastimil's patch + your change with stress for more than half hour, the bug
> I reported is gone :)
Good to hear!
> I have some questions, Joonsoo, you provided a patch as following:
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 3a7a67b..952a8a3 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -448,7 +448,10 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
>
> VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
>
> + mutex_lock(&cma_mutex);
> free_contig_range(pfn, count);
> + mutex_unlock(&cma_mutex);
> +
> cma_clear_bitmap(cma, pfn, count);
> trace_cma_release(pfn, pages, count);
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f32950..68ed5ae 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1559,7 +1559,8 @@ void free_hot_cold_page(struct page *page, bool cold)
> * excessively into the page allocator
> */
> if (migratetype >= MIGRATE_PCPTYPES) {
> - if (unlikely(is_migrate_isolate(migratetype))) {
> + if (is_migrate_cma(migratetype) ||
> + unlikely(is_migrate_isolate(migratetype))) {
> free_one_page(zone, page, pfn, 0, migratetype);
> goto out;
> }
>
> This patch also works to fix the bug, why not just use this one? is there
> any side effects for this patch? maybe there is performance issue as the
> mutex lock is used, any other issues?
The changes in free_hot_cold_page() would cause unacceptable performance
problem in a big machine, because, with above change, it takes zone->lock
whenever freeing one page on CMA region.
Thanks.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-07 05:40 +0100
Re: Suspicious error for CMA stress test "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> - 2016-03-07 09:20 +0100
Re: Suspicious error for CMA stress test Laura Abbott <labbott@redhat.com> - 2016-03-07 19:50 +0100
Re: Suspicious error for CMA stress test "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> - 2016-03-08 03:00 +0100
Re: Suspicious error for CMA stress test "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> - 2016-03-09 02:30 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-11 16:10 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-11 18:10 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-14 07:50 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-14 08:10 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-14 08:20 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-14 13:40 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-14 15:20 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-16 13:10 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-16 10:50 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-17 08:00 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-17 10:30 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-17 16:40 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-18 03:20 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-17 16:50 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-17 17:00 +0100
Re: Suspicious error for CMA stress test Lucas Stach <l.stach@pengutronix.de> - 2016-03-18 14:40 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-21 05:50 +0100
Re: Suspicious error for CMA stress test Lucas Stach <l.stach@pengutronix.de> - 2016-03-22 16:00 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-23 05:50 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-18 15:20 +0100
Re: Suspicious error for CMA stress test Lucas Stach <l.stach@pengutronix.de> - 2016-03-18 15:50 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-18 22:00 +0100
Re: Suspicious error for CMA stress test Lucas Stach <l.stach@pengutronix.de> - 2016-03-22 15:50 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-19 08:30 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-19 23:20 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-23 05:50 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-23 09:30 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-23 09:40 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-18 13:30 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <hanjun.guo@linaro.org> - 2016-03-08 05:10 +0100
Re: Suspicious error for CMA stress test Vlastimil Babka <vbabka@suse.cz> - 2016-03-07 14:00 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-08 08:50 +0100
Re: Suspicious error for CMA stress test Xishi Qiu <qiuxishi@huawei.com> - 2016-03-08 11:50 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-08 16:40 +0100
Re: Suspicious error for CMA stress test Xishi Qiu <qiuxishi@huawei.com> - 2016-03-09 03:20 +0100
csiph-web