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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23617C77B75 for ; Mon, 15 May 2023 15:08:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8263C900005; Mon, 15 May 2023 11:08:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D657900002; Mon, 15 May 2023 11:08:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69E55900005; Mon, 15 May 2023 11:08:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5A916900002 for ; Mon, 15 May 2023 11:08:31 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 313521A12EE for ; Mon, 15 May 2023 15:08:31 +0000 (UTC) X-FDA: 80792820822.04.C4E777C Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf10.hostedemail.com (Postfix) with ESMTP id 5824FC0043 for ; Mon, 15 May 2023 15:08:13 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=KpmrJ2n0; spf=none (imf10.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684163294; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cwWX1J8jmE9CcWWNEepi0uSPUXS9Vb5N2uT4ZDVIwkg=; b=e1vKeUvMFTxvrokvsgbZuZ6rVjlG9GCEinIZ4M90ALxX4RDHY1V2xa9e7YyGYfJUdLzPJX H9gGa0Y0Oj625Sba07j8tMbTdpQ6QP/pN7ATll+k7PwU/9sGxUxgwTqrr/oLQI9WaBK7MG YlmjevOYu86V7MYbatTZpoHgAA/40qY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=KpmrJ2n0; spf=none (imf10.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684163294; a=rsa-sha256; cv=none; b=OEXZSnhAa2S6CvEPbg6hGo8AEt1VXZ0M/aDbD7SMbNifAWMzwTMdIyEBP0VgI6sFlfHoyc n+LnM4GaarPfj0SjI85Nne2ZY/oiV5MeXny41ads5gQ9OuLkIo9/OBNTiJxQHBLcoSaE+A jcyBkyXxM2A8FeVJrwdgcDL/l3bCIHw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=cwWX1J8jmE9CcWWNEepi0uSPUXS9Vb5N2uT4ZDVIwkg=; b=KpmrJ2n0w3STusTXAwtbRnA94l R5nXBr4Mw837OBfh7cMHo0iUTSo47DnQX8UL3HEkUEhK3QdStkQ8VP5WzGTHS032mGKQ4FNiF930z KsYquS9AFOgavZOtY+6ORRtuVFeHdX32LA7zN5WgtyCZ4daHWWdyu0/W8UDYzu0GPlBzVDR/8NTZk gQlrNCLicQYoqkfvnSBt1x3XxnCz70U+jqilLVCpJWr8Vksp9757R0402bkXaoMNhGdXJpJHL8/eT jlfSPBZ0YCTlsLIh6Sngpi6CDz9i1Q/REsYQPb2EasGA+eAgZsOvxJLwMT25Thhk3k5POkRoDeN9s 7mFFkjVw==; Received: from [2601:1c2:980:9ec0::2764] by bombadil.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1pyZo3-002W0c-0L; Mon, 15 May 2023 15:08:11 +0000 Message-ID: Date: Mon, 15 May 2023 08:08:08 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [PATCH] mm/secretmem: make it on by default Content-Language: en-US To: Mike Rapoport , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230515083400.3563974-1-rppt@kernel.org> From: Randy Dunlap In-Reply-To: <20230515083400.3563974-1-rppt@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5824FC0043 X-Stat-Signature: ib8e79rwt8usfqifny79qgt4b7ww5utt X-HE-Tag: 1684163293-816707 X-HE-Meta: U2FsdGVkX1+92zRyxI4yPNLHakBwfA/0bGFcTpbdUVS36VO22Zh6OwhevXA6CJWFLKTQ/E2F7VK5qloccNylN8j97e1pjXQJqciE00KIDDSkYQL/lGIyntG9okuFyPbRgI3Ns2o16frw6TMns36BMbZcxaxq+bYWybkq559laxk0iS2fz+WvciHtJ0eoupXeu1hVB/NJ8loeMf5pugmT/dKX3H50DQEQv6kMnj3L2Y8EmzIKlfJu+wzSPkqJBvRIpJ1yft5cpnSKlKGdJYxmgj0xWrowGaNaZcZPF5CSjZvdkDkT4GtJEniXRySbZfAoRTrzqBW+E3G52KpitmhKSFj3anL3xE2xRtLm6UmZZllUi+efcyQWj3K5ptt/hHBaNQzqTV84JlqGpC0uVeWyN1mTIJIRQhnwudH9rL4yvcGGWpiQk0Ocx9r316c1fNa7NX3qJ8NwmL8dTql8VIMSVLoY1IqSi87257XK/iVEcWrPDnE5tq2uyLDvJ48zoGBLKgTl5Q1MtKgTPzTpnEUn7vLlE8Am6RGRQuYrJm5xUcjUrwgS0vyc4II/7gLjGw+TJyjT5GDX52wOfXM6VhNszx2y6kBUlSMcQHxLIr3t9PmD2+H7OZXX7zrRFuWVYFeAGZt7hBkucGJZGOtCFtUAJVOLK6z5VQUl4tPv+rRqlT2s0CpOZE5EVPaEtvkYxyCY0TYVFn/e3aHNfsuNiHVWrm4guoc8noAntoa/jWeFT2/6upDFUPWgYPBAOYSYuaNHhAxkAay8x55U/E6PatwIET8agxqt9kSCMo7L4S9DbeK7EpWCVm18BRffuWXH6nY+h1Egx66FlN4/gCbJR4xqYf/jir1cc7nsvBf3X+4TOHfytVw44Ja6yLwyRc6eBIsHCnqeuV4Fy2sIKTKbmQDX/aGp5RFXc3TRKrXM+cIGgBuSRBO+v860PgfNSUIqd0i6rwmT91BsCg2l5ZI28iE okQ/vbrj LyNyzTSpT03omXrgvVehl8V8mYL9vAXD8U1MAhJczmJJEBYyaDEG29LpiI3K66icRCUnDE7KW6Sqdc3vEPk/x7JMc366Ha8b6fzKfB2FQr6grD31xG1XewIF7smpkSfd/mJkuX+ygiA6u0j/b6Vo4Y/weiH4kIgqv1sfGF8q54lhwPlae4lbH3fI3gEGHhQTdVIBfPSicWdzsU8F2aVDeV4tycFEJLvSWU0i4NkVHt/Frtxg8UbgKadRhoVt0Y97iPQwROD9+yC8xtiqo40Esr+5G1clQ5kmXcmF7M8WeckCFA+m+XCjY6BUWY62VJoVeBfZJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, On 5/15/23 01:34, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Following the discussion about direct map fragmentaion at LSF/MM [1], it > appears that direct map fragmentation has a negligible effect on kernel > data accesses. Since the only reason that warranted secretmem to be > disabled by default was concern about performance regression caused by > the direct map fragmentation, it makes perfect sense to lift this > restriction and make secretmem enabled. > > secretmem obeys RLIMIT_MEMBLOCK and as such it is not expected to cause > large fragmentation of the direct map or meaningfull increase in page > tables allocated during split of the large mappings in the direct map. > > The secretmem.enable parameter is retained to allow system > administrators to disable secretmem at boot. > > Switch the default setting of secretem.enable parameter to 1. Nit: secretmem.enable Maybe fix up while applying. > > Link: https://lwn.net/Articles/931406/ [1] > Signed-off-by: Mike Rapoport (IBM) > --- > mm/secretmem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/secretmem.c b/mm/secretmem.c > index 0b502625cd30..974b32ba8b9d 100644 > --- a/mm/secretmem.c > +++ b/mm/secretmem.c > @@ -35,7 +35,7 @@ > #define SECRETMEM_MODE_MASK (0x0) > #define SECRETMEM_FLAGS_MASK SECRETMEM_MODE_MASK > > -static bool secretmem_enable __ro_after_init; > +static bool secretmem_enable __ro_after_init = 1; > module_param_named(enable, secretmem_enable, bool, 0400); > MODULE_PARM_DESC(secretmem_enable, > "Enable secretmem and memfd_secret(2) system call"); -- ~Randy