Re: [PATCH/RFC] mm: do not regard CMA pages as free on watermark check

[Vitaly Wool <vitalywool@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

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
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
(otherwise redundant) low memory killer operations, so I decided to propose
a safer method instead.

Best regards,
   Vitaly

[-- Attachment #2: Type: text/html, Size: 2930 bytes --]