From: Vlastimil Babka <vbabka@suse.cz>
To: Vitaly Wool <vitalywool@gmail.com>, Laura Abbott <labbott@redhat.com>
Cc: Vitaly Wool <vwool@hotmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH/RFC] mm: do not regard CMA pages as free on watermark check
Date: Thu, 10 Sep 2015 08:39:24 +0200 [thread overview]
Message-ID: <55F1259C.3020006@suse.cz> (raw)
In-Reply-To: <CAMJBoFNsCuktUC0aZF6Xw05v4g_2eK1G183KkSkhQYkztEVHCA@mail.gmail.com>
[CC Joonsoo, Mel]
On 09/09/2015 08:31 PM, Vitaly Wool wrote:
> Hi Laura,
>
> On Wed, Sep 9, 2015 at 7:56 PM, Laura Abbott <labbott@redhat.com> wrote:
>
>> (cc-ing linux-mm)
>> On 09/09/2015 07:44 AM, Vitaly Wool wrote:
>>
>>> __zone_watermark_ok() does not corrrectly take high-order
>>> CMA pageblocks into account: high-order CMA blocks are not
>>> removed from the watermark check. Moreover, CMA pageblocks
>>> may suddenly vanish through CMA allocation, so let's not
>>> regard these pages as free in __zone_watermark_ok().
>>>
>>> This patch also adds some primitive testing for the method
>>> implemented which has proven that it works as it should.
>>>
>>>
>> The choice to include CMA as part of watermarks was pretty deliberate.
>> Do you have a description of the problem you are facing with
>> the watermark code as is? Any performance numbers?
>>
>>
> let's start with facing the fact that the calculation in
> __zone_watermark_ok() is done incorrectly for the case when ALLOC_CMA is
> not set. While going through pages by order it is implicitly considered
You're not the first who tried to fix it, I think Joonsoo tried as well?
I think the main objection was against further polluting fastpaths due to CMA.
Note that Mel has a patchset removing high-order watermark checks (in the last
patch of https://lwn.net/Articles/655406/ ) so this will be moot afterwards.
> that CMA pages can be used and this impacts the result of the function.
>
> This can be solved in a slightly different way compared to what I proposed
> but it needs per-order CMA pages accounting anyway. Then it would have
> looked like:
>
> for (o = 0; o < order; o++) {
> /* At the next order, this order's pages become unavailable
> */
> free_pages -= z->free_area[o].nr_free << o;
> #ifdef CONFIG_CMA
> if (!(alloc_flags & ALLOC_CMA))
> free_pages -= z->free_area[o].nr_free_cma << o;
> /* Require fewer higher order pages to be free */
> min >>= 1;
> ...
>
> But what we have also seen is that CMA pages may suddenly disappear due to
> CMA allocator work so the whole watermark checking was still unreliable,
> causing compaction to not run when it ought to and thus leading to
Well, watermark checking is inherently racy. CMA pages disappearing is no
exception, non-CMA pages may disappear as well.
> (otherwise redundant) low memory killer operations, so I decided to propose
> a safer method instead.
>
> Best regards,
> Vitaly
>
--
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: Vitaly Wool <vitalywool@gmail.com>, Laura Abbott <labbott@redhat.com>
Cc: Vitaly Wool <vwool@hotmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH/RFC] mm: do not regard CMA pages as free on watermark check
Date: Thu, 10 Sep 2015 08:39:24 +0200 [thread overview]
Message-ID: <55F1259C.3020006@suse.cz> (raw)
In-Reply-To: <CAMJBoFNsCuktUC0aZF6Xw05v4g_2eK1G183KkSkhQYkztEVHCA@mail.gmail.com>
[CC Joonsoo, Mel]
On 09/09/2015 08:31 PM, Vitaly Wool wrote:
> Hi Laura,
>
> On Wed, Sep 9, 2015 at 7:56 PM, Laura Abbott <labbott@redhat.com> wrote:
>
>> (cc-ing linux-mm)
>> On 09/09/2015 07:44 AM, Vitaly Wool wrote:
>>
>>> __zone_watermark_ok() does not corrrectly take high-order
>>> CMA pageblocks into account: high-order CMA blocks are not
>>> removed from the watermark check. Moreover, CMA pageblocks
>>> may suddenly vanish through CMA allocation, so let's not
>>> regard these pages as free in __zone_watermark_ok().
>>>
>>> This patch also adds some primitive testing for the method
>>> implemented which has proven that it works as it should.
>>>
>>>
>> The choice to include CMA as part of watermarks was pretty deliberate.
>> Do you have a description of the problem you are facing with
>> the watermark code as is? Any performance numbers?
>>
>>
> let's start with facing the fact that the calculation in
> __zone_watermark_ok() is done incorrectly for the case when ALLOC_CMA is
> not set. While going through pages by order it is implicitly considered
You're not the first who tried to fix it, I think Joonsoo tried as well?
I think the main objection was against further polluting fastpaths due to CMA.
Note that Mel has a patchset removing high-order watermark checks (in the last
patch of https://lwn.net/Articles/655406/ ) so this will be moot afterwards.
> that CMA pages can be used and this impacts the result of the function.
>
> This can be solved in a slightly different way compared to what I proposed
> but it needs per-order CMA pages accounting anyway. Then it would have
> looked like:
>
> for (o = 0; o < order; o++) {
> /* At the next order, this order's pages become unavailable
> */
> free_pages -= z->free_area[o].nr_free << o;
> #ifdef CONFIG_CMA
> if (!(alloc_flags & ALLOC_CMA))
> free_pages -= z->free_area[o].nr_free_cma << o;
> /* Require fewer higher order pages to be free */
> min >>= 1;
> ...
>
> But what we have also seen is that CMA pages may suddenly disappear due to
> CMA allocator work so the whole watermark checking was still unreliable,
> causing compaction to not run when it ought to and thus leading to
Well, watermark checking is inherently racy. CMA pages disappearing is no
exception, non-CMA pages may disappear as well.
> (otherwise redundant) low memory killer operations, so I decided to propose
> a safer method instead.
>
> Best regards,
> Vitaly
>
next prev parent reply other threads:[~2015-09-10 6:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 14:44 [PATCH/RFC] mm: do not regard CMA pages as free on watermark check Vitaly Wool
2015-09-09 17:56 ` Laura Abbott
2015-09-09 17:56 ` Laura Abbott
2015-09-09 18:31 ` Vitaly Wool
2015-09-10 6:39 ` Vlastimil Babka [this message]
2015-09-10 6:39 ` Vlastimil Babka
2015-09-10 8:48 ` Vitaly Wool
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=55F1259C.3020006@suse.cz \
--to=vbabka@suse.cz \
--cc=iamjoonsoo.kim@lge.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=vitalywool@gmail.com \
--cc=vwool@hotmail.com \
/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.