Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5563651imu; Tue, 13 Nov 2018 08:23:56 -0800 (PST) X-Google-Smtp-Source: AJdET5eG4r6fZe8V/hARtNQPr3Fsb30XorXRmrEVDbHSj4k0PgaQUX8A5THvY/wF11brLpYR5/Di X-Received: by 2002:a17:902:bd8e:: with SMTP id q14mr1487669pls.146.1542126236212; Tue, 13 Nov 2018 08:23:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542126236; cv=none; d=google.com; s=arc-20160816; b=teVsoRQdIg3RkZhGjp29i+gePlZGbvXq9O6LbM7WNSjr54hDEsGb+TnaaqlBi9uw9F /Yl8OB6rw8RrFDzCe03cqNi1mAPbSUJ5WrS/2g0PGHV3/t1vw7DiIsCOMn4UljBRPCZG 3H7iWOQWfI5l8t0BqS4n2+D1IuT9O65/smZSNNVCr9oI7Svb17daS/Qc8Yc/W4+sM2CY NC1g/LdyaMHhpau2BWZZHmDmyGro+CtT3WWmyHptAPtxUnt33q9KJNmDrN3+I30IKAQW S0BqPM4qKny7SNtTZp520Pmhyxf6lzC/mN3iU2vHYC+qK2s+Mrd/rCaRF6WaMXJvYHQC KsSQ== 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:message-id:subject:cc:to:from:date :dkim-signature; bh=6JsbnoU4Aw76pDPxU5YxMsvwhrQ8iPsdY1+qhxQ6Ppc=; b=eUJQYRZD0BlXXnUgV8S9XcMt9Rw2FJk4P+sfjzesnLtN16Ux43NhFgjaPTHMzG6M25 j/Xgxq+DUlSMYnsHNo4f/H7POi5Qgrh83MsnWjjpZV2KPhztU8runHbEVeWn9JOcIMH/ PT9DfzjyYWl8U4UlCv0KToY3BQpVPDW3lsBZxJibavqd23W7EhiC2z+0L/VnKTjwnhfj y3lsPhOdDjRXXQSAEoFxoaC6k1C3eIjcED+3G+FllOjUkv1Hdx1PN9G9TNAC+NFwGBpm GwWRiiML1AnxG9VkK2gAuZIlGiJ1ZxM9kUokhypDy4+wc2wzjWsWCOeDVWakSfzwtB4j p4WQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RwkjR1eb; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4-v6si21155215pla.203.2018.11.13.08.23.24; Tue, 13 Nov 2018 08:23:56 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=RwkjR1eb; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730841AbeKNCUm (ORCPT + 99 others); Tue, 13 Nov 2018 21:20:42 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:44988 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726721AbeKNCUm (ORCPT ); Tue, 13 Nov 2018 21:20:42 -0500 Received: by mail-pf1-f194.google.com with SMTP id b81-v6so5801604pfe.11 for ; Tue, 13 Nov 2018 08:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=6JsbnoU4Aw76pDPxU5YxMsvwhrQ8iPsdY1+qhxQ6Ppc=; b=RwkjR1ebP9hB1Haw7oDY11DkD20eLNDpntQH7nibk6BDY2iosxIutC9BPC/zDXgwH/ iluuy4xjTOZlaOnQbSb/SXW1mPQC3FdmwYvKKI5u/YqGOr+8EEDGIl1rcKt9xFIdS2th zd3qLcYY55b4JNJTf+IPtA4TJlaUPTpGB/6PAnx0sqLo+iLtgZ9YVmXzVi21r562XI+u WhTE184Z56ECzu9yYm+DxMNhy6R/W1mK+3lV3lBmzDqQtIlS7XZT7ot58K8wgkJqHv7K KWvbcWPduu1Yv+6UKxYK1nirKKj3U1qh3oeWfMK5O/k3g1XRzKuVEwBdimqc2QFWeuhY 9teQ== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=6JsbnoU4Aw76pDPxU5YxMsvwhrQ8iPsdY1+qhxQ6Ppc=; b=D1QQ6pi2LWFbUc2hzpXUs/6hl/04TMHcDdLwa89tXtkjahMIosy7gV1ZIU02DDIyzO yDC8sXTkPk/bEYqCV84khjb60YULbcz/1iBRHPgddryXgOIQs4L63bAqQOfmPhQuVPhT iU2pwAQvzaBAY3r3IOKTalY+SvptKicQUroIXlxnbkaldoeoPTk3QKN8+uiRmBGzt7EZ hKbLYL+QuoNsWnZJpPgh60+MEU+jDqF98TOaoAPN0A4/IdXNX0M7IAxrGylS1miyna2X OI124d91kEhGcX+AeybGERY3UzBjUbHWcrCFCIh0dmo/DIDu7Twy32sEYK0+iiGT74B7 31Hw== X-Gm-Message-State: AGRZ1gI/6xL+qKdhA5wFzH0F9169rzkjniZtJSrmi4KRyNnBRnABgh/O 3c9eO3Gm8uatvcoZVD2mwDFCBQ== X-Received: by 2002:a63:1a4b:: with SMTP id a11mr5352918pgm.254.1542126114194; Tue, 13 Nov 2018 08:21:54 -0800 (PST) Received: from gnomeregan.cam.corp.google.com ([2620:15c:6:14:ad22:1cbb:d8fa:7d55]) by smtp.gmail.com with ESMTPSA id o86-v6sm25032013pfk.8.2018.11.13.08.21.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Nov 2018 08:21:53 -0800 (PST) Date: Tue, 13 Nov 2018 11:21:48 -0500 From: Barret Rhoden To: Paolo Bonzini Cc: Dan Williams , Dave Jiang , Ross Zwisler , Vishal Verma , Radim =?UTF-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Ingo Molnar , Borislav Petkov , linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org, "H. Peter Anvin" , x86@kernel.org, kvm@vger.kernel.org, yu.c.zhang@intel.com, yi.z.zhang@intel.com Subject: Re: [PATCH 2/2] kvm: Use huge pages for DAX-backed files Message-ID: <20181113112148.6205fc56@gnomeregan.cam.corp.google.com> In-Reply-To: <861c4adb-e2f0-2caf-8f6e-9f09ecb0b624@redhat.com> References: <20181109203921.178363-1-brho@google.com> <20181109203921.178363-3-brho@google.com> <861c4adb-e2f0-2caf-8f6e-9f09ecb0b624@redhat.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-11-12 at 20:31 Paolo Bonzini wrote: > Looks good. What's the plan for removing PageReserved from DAX pages? I hear that's going on in this thread: https://lore.kernel.org/lkml/154145268025.30046.11742652345962594283.stgit@ahduyck-desk1.jf.intel.com/ Though it looks like it's speeding up page initialization, and not explicitly making the PageReserved change, yet. Alternatively, I could change kvm_is_reserved_pfn() to single out zone_device pages if we don't want to wait or if there is a concern that it won't happen. On a related note, there are two places in KVM where we check PageReserved outside of kvm_is_reserved_pfn(). For reference: bool kvm_is_reserved_pfn(kvm_pfn_t pfn) { if (pfn_valid(pfn)) return PageReserved(pfn_to_page(pfn)); return true; } One caller of PageReserved(): void kvm_set_pfn_dirty(kvm_pfn_t pfn) { if (!kvm_is_reserved_pfn(pfn)) { struct page *page = pfn_to_page(pfn); if (!PageReserved(page)) SetPageDirty(page); } } In that one, the PageReserved() check looks redundant, since if the page was PageReserved, then it would have been kvm_is_reserved. The other is: static bool kvm_is_mmio_pfn(kvm_pfn_t pfn) { if (pfn_valid(pfn)) return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) && /* * Some reserved pages, such as those from NVDIMM * DAX devices, are not for MMIO, and can be mapped * with cached memory type for better performance. * However, the above check misconceives those pages * as MMIO, and results in KVM mapping them with UC * memory type, which would hurt the performance. * Therefore, we check the host memory type in addition * and only treat UC/UC-/WC pages as MMIO. */ (!pat_enabled() || pat_pfn_immune_to_uc_mtrr(pfn)); return true; } Where the PAT stuff was motivated by DAX. The PageReserved check here looks like a broken-out version of kvm_is_reserved_pfn(), so that we can make some extra checks around it. Anyway, I can get rid of those two PageReserved checks and/or have kvm_is_reserved_pfn() just check DAX pages, if everyone is OK with that. Thanks, Barret