Hi Laura,
On Wed, Sep 9, 2015 at 7:56 PM, Laura Abbott <labbott@xxxxxxxxxx> 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