Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7296145imu; Mon, 3 Dec 2018 10:33:03 -0800 (PST) X-Google-Smtp-Source: AFSGD/X+kfBQIxruUhopk192Tz8TKfX5VydHyUxupn87nWGOjGdUC0noZaUKh93gJ+jBYc+QxufC X-Received: by 2002:a62:1447:: with SMTP id 68mr16702132pfu.257.1543861983456; Mon, 03 Dec 2018 10:33:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543861983; cv=none; d=google.com; s=arc-20160816; b=ZXylFDr3tA1sgW46f0QrZMv8II3uz7/NIzYFbxK+m2IC9cvLnVbhOFqZ6m+rbVOC9T KfudOMnliTJRjH5YYtrHsGdQ7wiWtrPGx8U4gVthmoyFq9XzQtvcPJvEB3RPUWoY4OCo Ah/t4akL3Vyc5Tg3C0kivQU5fysFU1C7cYC5JksIiTTz9orDpL6oHZ8GNLm4ySm2gGNA Nl1ndr0COI27CTTFddMSKGOAN4FSZGEEGbbZ7E4Y9xZo4mJ78EUBAWf3Tuv91X1H2TRm KOgPE4hYOQc09Nr8dU+kfsbaksQnkoWOdSCBNaVAlmGxvUtJH0O0++hBa/pjT8AG+2ub /Nyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=CQt0iM3EDtfkEGIVgafMbUMIZrZyz/WVKJIR0O202ac=; b=M6viz6TVqh52MqDNVhqc+gybd4aacv8L9A2sajkvlw+8QzBNvFQrk01TVr1C8BKJlf 5i2ABuRAkLUyBvVSXRmMFH/RuTS8rcvJTGa6LT6Bok3saQUnnlnAlTD5OKnNQHHNnR7w GMWakwFcVtFyl3bwkoUuP5Qr51HxgRpY0SBcFEs38G1HstMHU3R1H3bWAOw3Kql8YLHe uJzqZdyMxoxg7G6cUsN9kvdQE6Yy+0zYjfyKYkzmbPgDwqJ/djHEEz3zZW1zdSICwF2j QmRLcK0T7SBQso3KCtg++94A5LFLxGmenlROLae9kXRJD6LWnTks4afnm0++fdaP1agc 9VEg== 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 19si12085647pgq.215.2018.12.03.10.32.39; Mon, 03 Dec 2018 10:33:03 -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 S1726882AbeLCScD (ORCPT + 99 others); Mon, 3 Dec 2018 13:32:03 -0500 Received: from mga14.intel.com ([192.55.52.115]:29573 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726693AbeLCScD (ORCPT ); Mon, 3 Dec 2018 13:32:03 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2018 10:32:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,311,1539673200"; d="scan'208";a="115586726" Received: from ahduyck-desk1.amr.corp.intel.com ([10.7.198.76]) by orsmga001.jf.intel.com with ESMTP; 03 Dec 2018 10:32:00 -0800 Message-ID: <714716fde90865e195848f1a9a38e9134e75ad29.camel@linux.intel.com> Subject: Re: [PATCH v2 0/3] kvm: Use huge pages for DAX-backed files From: Alexander Duyck To: Barret Rhoden , Dan Williams Cc: Dave Jiang , zwisler@kernel.org, Vishal L Verma , Paolo Bonzini , rkrcmar@redhat.com, Thomas Gleixner , Ingo Molnar , Borislav Petkov , linux-nvdimm , Linux Kernel Mailing List , "H. Peter Anvin" , X86 ML , KVM list , "Zhang, Yu C" , "Zhang, Yi Z" Date: Mon, 03 Dec 2018 10:32:00 -0800 In-Reply-To: <20181203124051.05c1d2ce@gnomeregan.cam.corp.google.com> References: <20181109203921.178363-1-brho@google.com> <20181114215155.259978-1-brho@google.com> <20181203124051.05c1d2ce@gnomeregan.cam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-12-03 at 12:40 -0500, Barret Rhoden wrote: > On 2018-11-14 at 16:55 Dan Williams wrote: > > [ add Alex who is looking into removing PageReserved for DAX pages. ] > > Thanks. I can keep my eye out for his patches and repost once that's > done. > > Alternatively, if you all want to merge this before the PageReserved / > DAX changes, then I can repost - just Ack/Review tags. It's harmless > with the existing PageReserved behavior. > > Thanks, > > Barret So the latest version of my generic memory init patches are up at: https://lore.kernel.org/lkml/154361452447.7497.1348692079883153517.stgit@ahduyck-desk1.amr.corp.intel.com/ To be honest I am not entirely convinced that dropping PageReserved is the right thing to do for DAX pages. I've been trying to work out a few different issues but not having much luck. It seems like the main issue is that the PageReserved bit is being used to indicate 2 different things in a few spots throughout the kernel. The definition of the PG_reserved flag reads like it should apply to DAX pages: PG_reserved is set for special pages, which can never be swapped out. Some of them might not even exist... PageReserved essentially means you aren't supposed to be migrating or swapping the page. The problem here is that I believe this logic should apply to DAX pages and so in many cases it makes sense to leave the flag set for DAX pages. Otherwise you have to go through and start special casing all the spots where normal memory falls through and add a check to see if we have a DAX page. The second use for the PG_reserved flag is to test for if you can pin the page or not. This I think is the reason why many are just assuming PageReserved == MMIO like KVM does. However this is a bad assumption to be making since the introduction of DAX, HMM, and P2PDMA allows MMIO memory to start doing different things like supporting pinning. I also believe it would be a bad reason to clear the flag for DAX pages. Thanks. - Alex