From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64F91C282CE for ; Tue, 9 Apr 2019 14:03:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3CAB32084F for ; Tue, 9 Apr 2019 14:03:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726573AbfDIODg (ORCPT ); Tue, 9 Apr 2019 10:03:36 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:45826 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726035AbfDIODf (ORCPT ); Tue, 9 Apr 2019 10:03:35 -0400 Received: by mail-qt1-f195.google.com with SMTP id v20so19788099qtv.12 for ; Tue, 09 Apr 2019 07:03:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=n26vjmHJGZ0EQn/mtrk4R3AZxBm3F/1GBg0P+TlV7oI=; b=s/XMXsPfQrFb0FNRJt4cDW5bFxcn1Poy96TP5sKrfcsvHHCtplHfnGetzMfIAy8pR8 XeN1vBj42CZa7risouFREwc9YFCdFyPrmGcjXLY7yeeNitPUR02pYuKXA17FmTFhDmCp 1Utw+2w6KtiBsboiXHSsv5O3Hw3jRj7BqE7UkCmwILc3ZQf8N5Cq2wJ9v5epD9cU2gC8 HbwgjK0BLzdOKB9hIwKLL/G1yRcRs1bf+8adJ9ZuLLKQbCSoLCcKTkpCh30J2ND5oDwh QWJwf4uxGZ1o8ZdxKfOpyhYg5UpsT1UYDrk8MpxlOSy02eGAYfi3R/m4DOrIXaW5Ajx5 96nA== X-Gm-Message-State: APjAAAVylD77EmpMksHEzOtE3XsGaRIaBNQ9tsa4H+KMoWiyj/XKcJCH OLShAjJGX6OxPp4jZgPwfT5+fQ== X-Google-Smtp-Source: APXvYqzc4JnkNzTNbpoLwYMEr8kUgiCAkWLAYuEbgd/jcCtrBJaBybfVSx4eANHPWt/JSh5F1czjjw== X-Received: by 2002:ac8:21bc:: with SMTP id 57mr28557365qty.51.1554818614779; Tue, 09 Apr 2019 07:03:34 -0700 (PDT) Received: from redhat.com (pool-173-76-246-42.bstnma.fios.verizon.net. [173.76.246.42]) by smtp.gmail.com with ESMTPSA id v129sm18139200qka.77.2019.04.09.07.03.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 Apr 2019 07:03:33 -0700 (PDT) Date: Tue, 9 Apr 2019 10:03:29 -0400 From: "Michael S. Tsirkin" To: David Hildenbrand Cc: Alexander Duyck , Nitesh Narayan Lal , kvm list , LKML , linux-mm , Paolo Bonzini , lcapitulino@redhat.com, pagupta@redhat.com, wei.w.wang@intel.com, Yang Zhang , Rik van Riel , dodgen@google.com, Konrad Rzeszutek Wilk , dhildenb@redhat.com, Andrea Arcangeli Subject: Re: Thoughts on simple scanner approach for free page hinting Message-ID: <20190409100258-mutt-send-email-mst@kernel.org> References: <20190409092625-mutt-send-email-mst@kernel.org> <43aa1bd2-4aac-5ac4-3bd4-fe1e4a342c79@redhat.com> <20190409093642-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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