Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp12198217imu; Tue, 1 Jan 2019 17:18:51 -0800 (PST) X-Google-Smtp-Source: ALg8bN52ImZCeFLOt2pjQHJ+M5x61vce/nfrFRe9TSlzfZXp0hiM80WCY+MajyuVLI8Go3z0llVP X-Received: by 2002:a17:902:82c2:: with SMTP id u2mr41778954plz.110.1546391931706; Tue, 01 Jan 2019 17:18:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546391931; cv=none; d=google.com; s=arc-20160816; b=yta0rE3m3WbUBm/4cuj6Zpv0FOPeg8uiYLZDyX0P1q/XzJL1WDBfdRKwcq/TX/C4Q6 0lG2zTfbBIsQ0pStNTZLg0kOLTkm/5zc57C+BsQFJdM7iqRe7LYylHja1WmdxPY/l3pZ voh4piDrASt7zKACBaY4oYvkOinnHDE6nvJALCNBbge4EdRZp6GWOy7mveKm5K3+i/Oh cO2XlXVezz21UV3qXmoyCcxu+lQKAIYX3WVwNqZcdQY//NepxJv48Ty+H2wFrVI5S7Tw MqtRc1RUQu5khPtkcA/WMPa07O/cB4oSaAHTwvE5IMVWpYnXw5vCPgycPpxOoSR26DjO CDmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=FoY+mffyqXVpyyp3+QIfw96CA9F6chxYhuPh+LZ/DeQ=; b=z7NMEXHKJDJXAIt1xO4ym0Wex99/4UZOpoaqV63ILQYdcyuPcprUXETnA2FrklFzbw 0INkm+UhUVXKBkig2S0nINIaFHFdUHa8Zs5SYl2ZSvbXABhar2OTWvav29lbIu523ceZ Z+MNFBIvhWGRKceX210BZTP9sh5lSjoj6VocbnXSaTyxt1AhDhWVd96q8sP9I5ymc5CB BMiyuUBHnGtRwxbDSOld2VvR7PeJY85H8JxODYqmz4YWVlH6nW9Nw9H1LyN1ZYHDhQXB H+4VXcCnZ9pymtjStwIlqyGodNxJ5t+z6q3iQEg0AsGar33nnJPgGLnIDYP29Zk5jEFS yKvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s13si32687671pgc.509.2019.01.01.17.18.36; Tue, 01 Jan 2019 17:18:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727946AbfABBB7 (ORCPT + 99 others); Tue, 1 Jan 2019 20:01:59 -0500 Received: from mga03.intel.com ([134.134.136.65]:19308 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727914AbfABBB6 (ORCPT ); Tue, 1 Jan 2019 20:01:58 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jan 2019 17:01:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,429,1539673200"; d="scan'208";a="106229491" Received: from yy-desk-7060.sh.intel.com (HELO localhost) ([10.239.161.32]) by orsmga008.jf.intel.com with ESMTP; 01 Jan 2019 17:01:55 -0800 Date: Wed, 2 Jan 2019 08:59:37 +0800 From: Yuan Yao To: "Aneesh Kumar K.V" Cc: Fengguang Wu , Andrew Morton , Linux Memory Management List , Yao Yuan , kvm@vger.kernel.org, LKML , Fan Du , Peng Dong , Huang Ying , Liu Jingqi , Dong Eddie , Dave Hansen , Zhang Yi , Dan Williams Subject: Re: [RFC][PATCH v2 11/21] kvm: allocate page table pages from DRAM Message-ID: <20190102005936.GA12352@yy-desk-7060> References: <20181226131446.330864849@intel.com> <20181226133351.703380444@intel.com> <87pntg7mv8.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pntg7mv8.fsf@linux.ibm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 01, 2019 at 02:53:07PM +0530, Aneesh Kumar K.V wrote: > Fengguang Wu writes: > > > From: Yao Yuan > > > > Signed-off-by: Yao Yuan > > Signed-off-by: Fengguang Wu > > --- > > arch/x86/kvm/mmu.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > --- linux.orig/arch/x86/kvm/mmu.c 2018-12-26 20:54:48.846720344 +0800 > > +++ linux/arch/x86/kvm/mmu.c 2018-12-26 20:54:48.842719614 +0800 > > @@ -950,6 +950,16 @@ static void mmu_free_memory_cache(struct > > kmem_cache_free(cache, mc->objects[--mc->nobjs]); > > } > > > > +static unsigned long __get_dram_free_pages(gfp_t gfp_mask) > > +{ > > + struct page *page; > > + > > + page = __alloc_pages(GFP_KERNEL_ACCOUNT, 0, numa_node_id()); > > + if (!page) > > + return 0; > > + return (unsigned long) page_address(page); > > +} > > + > > May be it is explained in other patches. What is preventing the > allocation from pmem here? Is it that we are not using the memory > policy prefered node id and hence the zone list we built won't have the > PMEM node? That because the PMEM nodes are memory-only node in the patchset, so numa_node_id() will always return the node id from DRAM nodes. About the zone list, yes in patch 10/21 we build the PMEM nodes to seperate zonelist, so DRAM nodes will not fall back to PMEM nodes. > > > static int mmu_topup_memory_cache_page(struct kvm_mmu_memory_cache *cache, > > int min) > > { > > @@ -958,7 +968,7 @@ static int mmu_topup_memory_cache_page(s > > if (cache->nobjs >= min) > > return 0; > > while (cache->nobjs < ARRAY_SIZE(cache->objects)) { > > - page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT); > > + page = (void *)__get_dram_free_pages(GFP_KERNEL_ACCOUNT); > > if (!page) > > return cache->nobjs >= min ? 0 : -ENOMEM; > > cache->objects[cache->nobjs++] = page; > > -aneesh >