Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1348050 > unrolled thread
| Started by | Hanjun Guo <guohanjun@huawei.com> |
|---|---|
| First post | 2016-03-02 15:00 +0100 |
| Last post | 2016-03-07 05:50 +0100 |
| Articles | 4 on this page of 44 — 8 participants |
Back to article view | Back to linux.kernel
Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-02 15:00 +0100
Re: Suspicious error for CMA stress test Laura Abbott <labbott@redhat.com> - 2016-03-03 02:30 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-03 07:30 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <js1304@gmail.com> - 2016-03-03 08:50 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-03 09:00 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-03 14:00 +0100
Re: Suspicious error for CMA stress test Laura Abbott <labbott@redhat.com> - 2016-03-03 20:00 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-04 03:10 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-04 07:20 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-04 03:10 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-04 05:40 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-04 07:10 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-04 07:40 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-04 08:40 +0100
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 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 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
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-04 06:40 +0100
Re: Suspicious error for CMA stress test Xishi Qiu <qiuxishi@huawei.com> - 2016-03-08 02:50 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-08 09:10 +0100
Re: Suspicious error for CMA stress test Hanjun Guo <guohanjun@huawei.com> - 2016-03-04 08:10 +0100
Re: Suspicious error for CMA stress test Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-07 05:50 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Xishi Qiu <qiuxishi@huawei.com> |
|---|---|
| Date | 2016-03-08 02:50 +0100 |
| Message-ID | <raeWC-2tf-11@gated-at.bofh.it> |
| In reply to | #1349853 |
On 2016/3/4 13:33, Hanjun Guo wrote:
> Hi Joonsoo,
>
> On 2016/3/4 10:02, Joonsoo Kim wrote:
>> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
>>> 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:
>> Thanks! Now, I can re-generate erronous situation you mentioned.
>>
>>> - 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:
>> [1] would not be sufficient to close this race.
>>
>> Try following things [A]. And, for more accurate test, I changed code a bit more
>> to prevent kernel page allocation from cma area [B]. This will prevent kernel
>> page allocation from cma area completely so we can focus cma_alloc/release race.
>>
>> Although, this is not correct fix, it could help that we can guess
>> where the problem is.
>>
>> Thanks.
>>
>> [A]
>
> I tested this solution [A], it can fix the problem, as you are posting a new patch, I will
> test that one and leave [B] alone :)
>
Hi Joonsoo,
How does this problem happen? Why the count is larger than total?
Patch A prevent the cma page free to pcp, right?
...
- if (unlikely(is_migrate_isolate(migratetype))) {
+ if (is_migrate_cma(migratetype) ||
+ unlikely(is_migrate_isolate(migratetype))) {
...
Thanks,
Xishi Qiu
> Thanks
> Hanjun
>
>
>
> .
>
[toc] | [prev] | [next] | [standalone]
| From | Joonsoo Kim <iamjoonsoo.kim@lge.com> |
|---|---|
| Date | 2016-03-08 09:10 +0100 |
| Message-ID | <rakSn-6EA-35@gated-at.bofh.it> |
| In reply to | #1352543 |
On Tue, Mar 08, 2016 at 09:42:00AM +0800, Xishi Qiu wrote:
> On 2016/3/4 13:33, Hanjun Guo wrote:
>
> > Hi Joonsoo,
> >
> > On 2016/3/4 10:02, Joonsoo Kim wrote:
> >> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
> >>> 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:
> >> Thanks! Now, I can re-generate erronous situation you mentioned.
> >>
> >>> - 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:
> >> [1] would not be sufficient to close this race.
> >>
> >> Try following things [A]. And, for more accurate test, I changed code a bit more
> >> to prevent kernel page allocation from cma area [B]. This will prevent kernel
> >> page allocation from cma area completely so we can focus cma_alloc/release race.
> >>
> >> Although, this is not correct fix, it could help that we can guess
> >> where the problem is.
> >>
> >> Thanks.
> >>
> >> [A]
> >
> > I tested this solution [A], it can fix the problem, as you are posting a new patch, I will
> > test that one and leave [B] alone :)
> >
>
> Hi Joonsoo,
>
> How does this problem happen? Why the count is larger than total?
>
> Patch A prevent the cma page free to pcp, right?
>
> ...
> - if (unlikely(is_migrate_isolate(migratetype))) {
> + if (is_migrate_cma(migratetype) ||
> + unlikely(is_migrate_isolate(migratetype))) {
> ...
> > .
> >
Even without free to pcp, bad merging could happen. Please see another
thread I mentioned some example.
Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Hanjun Guo <guohanjun@huawei.com> |
|---|---|
| Date | 2016-03-04 08:10 +0100 |
| Message-ID | <r8S25-2Yy-9@gated-at.bofh.it> |
| In reply to | #1349781 |
On 2016/3/4 10:02, Joonsoo Kim wrote:
> On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
>> 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:
> Thanks! Now, I can re-generate erronous situation you mentioned.
>
>> - 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:
> [1] would not be sufficient to close this race.
>
> Try following things [A]. And, for more accurate test, I changed code a bit more
> to prevent kernel page allocation from cma area [B]. This will prevent kernel
> page allocation from cma area completely so we can focus cma_alloc/release race.
>
> Although, this is not correct fix, it could help that we can guess
> where the problem is.
>
> Thanks.
>
> [A]
> diff --git a/mm/cma.c b/mm/cma.c
> index c003274..43ed02d 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -496,7 +496,9 @@ 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 c6c38ed..1ce8a59 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2192,7 +2192,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;
> }
As I replied in previous email, the solution will fix the problem, the Cma freed memory and
system freed memory is in sane state after apply above patch.
I also tested this situation which only apply the code below:
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 will not fix the problem, but will reduce the errorous freed number of memory,
hope this helps.
>
>
> [B]
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f2dccf9..c6c38ed 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1493,6 +1493,7 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,
> int alloc_flags)
> {
> int i;
> + bool cma = false;
>
> for (i = 0; i < (1 << order); i++) {
> struct page *p = page + i;
> @@ -1500,6 +1501,9 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,
> return 1;
> }
>
> + if (is_migrate_cma(get_pcppage_migratetype(page)))
> + cma = true;
> +
> set_page_private(page, 0);
> set_page_refcounted(page);
>
> @@ -1528,6 +1532,12 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,
> else
> clear_page_pfmemalloc(page);
>
> + if (cma) {
> + page_ref_dec(page);
mm/page_alloc.c: In function ‘prep_new_page’:
mm/page_alloc.c:1407:3: error: implicit declaration of function ‘page_ref_dec’ [-Werror=implicit-function-declaration]
page_ref_dec(page);
^
Typo?
Thanks
Hanjun
[toc] | [prev] | [next] | [standalone]
| From | Joonsoo Kim <iamjoonsoo.kim@lge.com> |
|---|---|
| Date | 2016-03-07 05:50 +0100 |
| Message-ID | <r9Vhg-6vm-1@gated-at.bofh.it> |
| In reply to | #1349903 |
On Fri, Mar 04, 2016 at 02:59:39PM +0800, Hanjun Guo wrote:
> On 2016/3/4 10:02, Joonsoo Kim wrote:
> > On Thu, Mar 03, 2016 at 08:49:01PM +0800, Hanjun Guo wrote:
> >> 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:
> > Thanks! Now, I can re-generate erronous situation you mentioned.
> >
> >> - 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:
> > [1] would not be sufficient to close this race.
> >
> > Try following things [A]. And, for more accurate test, I changed code a bit more
> > to prevent kernel page allocation from cma area [B]. This will prevent kernel
> > page allocation from cma area completely so we can focus cma_alloc/release race.
> >
> > Although, this is not correct fix, it could help that we can guess
> > where the problem is.
> >
> > Thanks.
> >
> > [A]
> > diff --git a/mm/cma.c b/mm/cma.c
> > index c003274..43ed02d 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -496,7 +496,9 @@ 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 c6c38ed..1ce8a59 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2192,7 +2192,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;
> > }
>
> As I replied in previous email, the solution will fix the problem, the Cma freed memory and
> system freed memory is in sane state after apply above patch.
>
> I also tested this situation which only apply the code below:
>
> 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 will not fix the problem, but will reduce the errorous freed number of memory,
> hope this helps.
>
> >
> >
> > [B]
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index f2dccf9..c6c38ed 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1493,6 +1493,7 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,
> > int alloc_flags)
> > {
> > int i;
> > + bool cma = false;
> >
> > for (i = 0; i < (1 << order); i++) {
> > struct page *p = page + i;
> > @@ -1500,6 +1501,9 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,
> > return 1;
> > }
> >
> > + if (is_migrate_cma(get_pcppage_migratetype(page)))
> > + cma = true;
> > +
> > set_page_private(page, 0);
> > set_page_refcounted(page);
> >
> > @@ -1528,6 +1532,12 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,
> > else
> > clear_page_pfmemalloc(page);
> >
> > + if (cma) {
> > + page_ref_dec(page);
>
> mm/page_alloc.c: In function ‘prep_new_page’:
> mm/page_alloc.c:1407:3: error: implicit declaration of function ‘page_ref_dec’ [-Werror=implicit-function-declaration]
> page_ref_dec(page);
> ^
I tested with linux-next and there is new mechanism to manipulate page
reference count and this is that. You can have same effect with
atomic_dec(&page->_count) in mainline kernel.
Thanks.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web