Received: by 10.223.185.116 with SMTP id b49csp2779613wrg; Mon, 5 Mar 2018 08:33:32 -0800 (PST) X-Google-Smtp-Source: AG47ELvrLcyT4uK6zl4vzW5IxgtNBUYi+ormvVljZM0hcwcf1waw+9YFy/+MPk7G3xF6DY82TxTi X-Received: by 10.98.33.204 with SMTP id o73mr15992022pfj.54.1520267612053; Mon, 05 Mar 2018 08:33:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520267612; cv=none; d=google.com; s=arc-20160816; b=tFjELjZqNJkltj5Z3pKXaRR3Fi/uc/47qzCuEYJRKlOw1yqMEdLeiZlCt0fnPm1svS 4oNykeLadCBNEa17YroxPr57Yj4KxGJBLxnitgaQC16aboQDq+llbpmx1d1NjmIQKsNF GtTyX5COMh7rIqQ0eUdlKFHs2xmku4IAy9vusgDz44R8Q3m3j3GVUyMjRrHQMd9OWuUZ Plq6SujJJiszeig1pz9Ngmw+151cHlzgLNF21eYdFvx/0a9yCEqFpl0VoZR/g8tqBYYK J2ZqUoGbw8vCNdfqFG0M7lC9mEV1MnAVNCVG3D/WGIMcjcj7DK7Ge/9KBln1j8Vgh1He qXCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=n+8qFBILcNhOM1tIyxMTIBZbfbLuP9X9KyGYe3PDGfo=; b=FtGgf2yOXytcwPWGxHhSCYPztsiexc9WSx96mYIV88wlsgOHV5FLFkv9m29Q3zhYmH 886Fb/sRTBrDFsYutZwnp8hK7UwbdSxOzSMIQ/ZMd3syafd3Z8XcZEQYQ1E9HQUvusnB Io2IfyH8f1j5/Hxl9FBFgVHAm/iR2YOdv0IJBbLXdTktpuYlIre2EO60XUBppwHucG+D 0/iCLxfosHq0NOqHJEuX/KUclj+zHW2TefIJX2Yvmi8UUghoMQXH0/L81j/hi9Agr3Zd +8kQpYFNZraH8jmN/Rmz6x9CMxX3ognROjdoQiJst6FD8xLyk9YRiK7CXEgSo/FTUGTo NxFg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n3si10373584pfi.302.2018.03.05.08.33.17; Mon, 05 Mar 2018 08:33:32 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932368AbeCEQav (ORCPT + 99 others); Mon, 5 Mar 2018 11:30:51 -0500 Received: from mga07.intel.com ([134.134.136.100]:9033 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752368AbeCEQ01 (ORCPT ); Mon, 5 Mar 2018 11:26:27 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2018 08:26:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,427,1515484800"; d="scan'208";a="39349290" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga002.jf.intel.com with ESMTP; 05 Mar 2018 08:26:24 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id 849E0607; Mon, 5 Mar 2018 18:26:20 +0200 (EET) From: "Kirill A. Shutemov" To: Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky Cc: Dave Hansen , Kai Huang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [RFC, PATCH 14/22] mm, khugepaged: Do not collapse pages in encrypted VMAs Date: Mon, 5 Mar 2018 19:26:02 +0300 Message-Id: <20180305162610.37510-15-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180305162610.37510-1-kirill.shutemov@linux.intel.com> References: <20180305162610.37510-1-kirill.shutemov@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pages for encrypted VMAs have to be allocated in a special way: we would need to propagate down not only desired NUMA node but also whether the page is encrypted. It complicates not-so-trivial routine of huge page allocation in khugepaged even more. I also puts more pressure on page allocator: we cannot re-use pages allocated for encrypted VMA to collapse page in unencrypted one or vice versa. I think for now it worth skipping encrypted VMAs. We can return to this topic later. Signed-off-by: Kirill A. Shutemov --- mm/khugepaged.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index b7e2268dfc9a..601151678414 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -830,6 +830,8 @@ static bool hugepage_vma_check(struct vm_area_struct *vma) return false; if (is_vma_temporary_stack(vma)) return false; + if (vma_is_encrypted(vma)) + return false; return !(vma->vm_flags & VM_NO_KHUGEPAGED); } -- 2.16.1