linux-kernel - Re: Thoughts on simple scanner approach for free page hinting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 9 Apr 2019 10:03:29 -0400
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Alexander Duyck <alexander.duyck@...il.com>,
        Nitesh Narayan Lal <nitesh@...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: Thoughts on simple scanner approach for free page hinting

On Tue, Apr 09, 2019 at 03:43:58PM +0200, David Hildenbrand wrote:
> On 09.04.19 15:37, Michael S. Tsirkin wrote:
> > On Tue, Apr 09, 2019 at 03:36:08PM +0200, David Hildenbrand wrote:
> >> On 09.04.19 15:31, Michael S. Tsirkin wrote:
> >>> On Tue, Apr 09, 2019 at 11:20:36AM +0200, David Hildenbrand wrote:
> >>>> BTW I like the idea of allocating pages that have already been hinted as
> >>>> last "choice", allocating pages that have not been hinted yet first.
> >>>
> >>> OK I guess but note this is just a small window during which
> >>> not all pages have been hinted.
> >>
> >> Yes, good point. It might sound desirable but might be completely
> >> irrelevant in practice.
> >>
> >>>
> >>> So if we actually think this has value then we need
> >>> to design something that will desist and not drop pages
> >>> in steady state too.
> >>
> >> By dropping, you mean dropping hints of e.g. MAX_ORDER - 1 or e.g. not
> >> reporting MAX_ORDER - 3?
> > 
> > I mean the issue is host unmaps the pages from guest right?  That is
> > what makes hinted pages slower than non-hinted ones.  If we do not want
> > that to happen for some pages, then either host can defer acting on the
> > hint, or we can defer hinting.
> 
> Ah right, I think what Alex mentioned is that pages processed in the
> hypervisor via MADVISE_FREE will be set RO, so the kernel can detect if
> they will actually be used again, resulting int
> 
> 1. A pagefault if written and the page(s) have not been reused by the host
> 2. A pagefault if read/written if the page(s) have been reused by the host
> 
> Now, assuming hinting is fast,  most pages will be hinted right away and
> therefore result in pagefaults. I think this is what you meant.
> 
> Deferring processing in the hypervisor cannot be done after a request
> has been marked as processed and handed back to the guest. (otherwise
> pages might already get reused)
> 
> So pages would have to "age" in the guest instead before they might be
> worth hinting. Marking pages as "Offline" alone won't help. Agreed.

Right. I don't see this as a blocker though. We can think about
strategies for addressing this after we have basic hinting
in place.

> -- 
> 
> Thanks,
> 
> David / dhildenb