Date:   Fri, 8 Mar 2019 14:10:20 -0500
From:   Nitesh Narayan Lal <nitesh@...hat.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     David Hildenbrand <david@...hat.com>,
        kvm list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        Paolo Bonzini <pbonzini@...hat.com>, lcapitulino@...hat.com,
        pagupta@...hat.com, wei.w.wang@...el.com,
        Yang Zhang <yang.zhang.wz@...il.com>,
        Rik van Riel <riel@...riel.com>, dodgen@...gle.com,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        dhildenb@...hat.com, Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free
 pages


On 3/8/19 1:06 PM, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@...hat.com> wrote:
>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>> The only other thing I still want to try and see if I can do is to add
>>> a jiffies value to the page private data in the case of the buddy
>>> pages.
>> Actually there's one extra thing I think we should do, and that is make
>> sure we do not leave less than X% off the free memory at a time.
>> This way chances of triggering an OOM are lower.
> If nothing else we could probably look at doing a watermark of some
> sort so we have to have X amount of memory free but not hinted before
> we will start providing the hints. It would just be a matter of
> tracking how much memory we have hinted on versus the amount of memory
> that has been pulled from that pool.
This is to avoid false OOM in the guest?
>  It is another reason why we
> probably want a bit in the buddy pages somewhere to indicate if a page
> has been hinted or not as we can then use that to determine if we have
> to account for it in the statistics.

The one benefit which I can see of having an explicit bit is that it
will help us to have a single hook away from the hot path within buddy
merging code (just like your arch_merge_page) and still avoid duplicate
hints while releasing pages.

I still have to check PG_idle and PG_young which you mentioned but I
don't think we can reuse any existing bits.

If we really want to have something like a watermark, then can't we use
zone->free_pages before isolating to see how many free pages are there
and put a threshold on it? (__isolate_free_page() does a similar thing
but it does that on per request basis).

>
>>> With that we could track the age of the page so it becomes
>>> easier to only target pages that are truly going cold rather than
>>> trying to grab pages that were added to the freelist recently.
>> I like that but I have a vague memory of discussing this with Rik van
>> Riel and him saying it's actually better to take away recently used
>> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
>> just confused?
> It is probably to cut down on the need for disk writes in the case of
> swap. If that is the case it ends up being a trade off.
>
> The sooner we hint the less likely it is that we will need to write a
> given page to disk. However the sooner we hint, the more likely it is
> we will need to trigger a page fault and pull back in a zero page to
> populate the last page we were working on. The sweet spot will be that
> period of time that is somewhere in between so we don't trigger
> unnecessary page faults and we don't need to perform additional swap
> reads/writes.
-- 
Regards
Nitesh



Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists