On Thu, Sep 10, 2015 at 8:39 AM, Vlastimil Babka <vbabka@suse.cz> wrote:

> [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.
>

I believe Joonsoo was calculating free_pages incorrectly, too, but in a
different way: he was subtracting CMA pages twice.


> 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.
>

I am not quite convinced that nested loops are a better solution than what
I suggest.


>
> > 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.
>

Right, that is why I decided to play on the safe side.

 ~vitaly