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=ham 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 9F6EFC43381 for ; Mon, 18 Feb 2019 02:31:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 79D52218DE for ; Mon, 18 Feb 2019 02:31:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728306AbfBRCb3 (ORCPT ); Sun, 17 Feb 2019 21:31:29 -0500 Received: from mga18.intel.com ([134.134.136.126]:23874 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727266AbfBRCb2 (ORCPT ); Sun, 17 Feb 2019 21:31:28 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2019 18:31:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,382,1544515200"; d="scan'208";a="134311016" Received: from unknown (HELO [10.239.13.114]) ([10.239.13.114]) by FMSMGA003.fm.intel.com with ESMTP; 17 Feb 2019 18:31:25 -0800 Message-ID: <5C6A1A28.40808@intel.com> Date: Mon, 18 Feb 2019 10:36:24 +0800 From: Wei Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: David Hildenbrand , 'Nitesh Narayan Lal' , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "pbonzini@redhat.com" , "lcapitulino@redhat.com" , "pagupta@redhat.com" , "yang.zhang.wz@gmail.com" , "riel@surriel.com" , "mst@redhat.com" , "dodgen@google.com" , "konrad.wilk@oracle.com" , "dhildenb@redhat.com" , "aarcange@redhat.com" Subject: Re: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting References: <20190204201854.2328-1-nitesh@redhat.com> <286AC319A985734F985F78AFA26841F73DF6B56A@shsmsx102.ccr.corp.intel.com> <286AC319A985734F985F78AFA26841F73DF6F0E3@shsmsx102.ccr.corp.intel.com> <286AC319A985734F985F78AFA26841F73DF71F38@shsmsx102.ccr.corp.intel.com> <751444f1-2ff8-e6f8-3501-b0408e3f6035@redhat.com> In-Reply-To: <751444f1-2ff8-e6f8-3501-b0408e3f6035@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/15/2019 05:41 PM, David Hildenbrand wrote: > On 15.02.19 10:05, Wang, Wei W wrote: >> On Thursday, February 14, 2019 5:43 PM, David Hildenbrand wrote: >>> Yes indeed, that is the important bit. They must not be put pack to the >>> buddy before they have been processed by the hypervisor. But as the pages >>> are not in the buddy, no one allocating a page will stumble over such a page >>> and try to allocate it. Threads trying to allocate memory will simply pick >>> another buddy page instead of "busy waiting" for that page to be finished >>> reporting. >> What if a guest thread try to allocate some pages but the buddy cannot satisfy >> because all the pages are isolated? Would it be the same case that the guest thread >> gets blocked by waiting all the isolated pages to get madvised by the host and >> returned to the guest buddy, or even worse, some guest threads get killed due to oom? > Your question targets low memory situations in the guest. I think Nitesh > already answered parts of that question somewhere and I'll let him > answer it in detail, only a short comment from my side :) > > I can imagine techniques where the OOM killer can be avoided, but the > OOM handler will eventually kick in and handle it. > > In general your question is valid and we will have to think about a way > to avoid that from happening. However, in contrast to your approach > blocking on potentially every page that is being hinted, in Nitesh's > approach this would only happen when the guest is really low on memory. > And the question is in general, if a guest wants to hint if low on > memory ("safety buffer"). I think we should forget that the guest is low on memory because this approach takes all the pages off the list, not because the guest really uses up the free memory. Guest allocating one page could also potentially be blocked until all the pages (as opposed to one page) being madvised and returned to the guest buddy. Best, Wei