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 59148C7619A for ; Mon, 27 Mar 2023 13:43:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B164900003; Mon, 27 Mar 2023 09:43:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76168900002; Mon, 27 Mar 2023 09:43:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 628A1900003; Mon, 27 Mar 2023 09:43:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 527B2900002 for ; Mon, 27 Mar 2023 09:43:33 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1E3724070B for ; Mon, 27 Mar 2023 13:43:33 +0000 (UTC) X-FDA: 80614795506.28.CB6F660 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf14.hostedemail.com (Postfix) with ESMTP id 2F158100005 for ; Mon, 27 Mar 2023 13:43:29 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=soLiZeMa; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679924610; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8roPEj8EC7N26IRrzr+bd955hd7RnrTWNtsdCvtyS6s=; b=lEmL2VVRPy4qJ/RjhQASOWipc5uTqTlWt8noSPebr9/FGoqOm/B/7c42rEe25Be42v41EQ agxT0yCwNCzgCcuXvaYz2PdIxMP4w7Suv38e8/jiAMWcpEiwHsQQ/rHtxuLO/CPIeFjf9q cTsE5JogFr0BYYnyhZdhvk4PUYlYibY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=soLiZeMa; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679924610; a=rsa-sha256; cv=none; b=4eyL8lHDP/09E57MLozI2by7xDjvOb8tR19kpNMULu76OwtUVSXOuC4ISgQlM5Y0Abx/6o 9npushLD99Hg0qxo1UxtCs9DQEsiZKdjsEUenExb1q7rvLK6ssfsvVEIQlolhxEQBteJeu pIiB5/O+FGleGdwcniVM0YcJ68LdQN4= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 830551FD72; Mon, 27 Mar 2023 13:43:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1679924608; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8roPEj8EC7N26IRrzr+bd955hd7RnrTWNtsdCvtyS6s=; b=soLiZeMaIxj/bgarNhrTFIq8Pw6Vxeq6Jh5s7kTHsfs3GgeDeYFC6V2u5rlEqjbWeaD8Yg 9EnZsaBANMRQZJeQ0h3gDFWDSoA7VS+pRuLiNmoEXKpkgrkd+kRj/Ka8EDza+60HAGCA+q HR7ABBaSn+yWkc2nHv44l2S4+U8Doqw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6166C13329; Mon, 27 Mar 2023 13:43:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id mZd1FYCdIWTpeAAAMHmgww (envelope-from ); Mon, 27 Mar 2023 13:43:28 +0000 Date: Mon, 27 Mar 2023 15:43:27 +0200 From: Michal Hocko To: Mike Rapoport Cc: linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Song Liu , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() Message-ID: References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2F158100005 X-Stat-Signature: b4dd84gw3wixw8a5n6jfjfqn9qqa98f3 X-HE-Tag: 1679924609-574683 X-HE-Meta: U2FsdGVkX1+y8qBLSuJR3Bv+LSq4RpZcdp00jVVhdnNu9/FZk37pvxwe7COi7iYGYI6h1dAqkqZOX336Ai52KwWzEdxcpVd+S92lqeK2J/LEjYVKyCIPjw6xJNb/1qc0DcyZX/tkWcU2Ra+5xzD0o45DzaBfYjHRgCOtedts8qqnLiZDbP9SQ5y2UZr2qB8mnP5zEo4HrdPL/RHLdoNENIinjSYYmAg0iikZsh+2ID7TBDe75lcmntgDvZBOGz2lV/Q8fnUNnSuxu/bkj8nlOefkGuBGqspw/YUnVfUq5vuLzbGDH/foXX6JsahXPC6ht/CWStN2MhWKgLlOjNSPsB0ECJxTInGId9ob7gGEyzBjn9ILtjcdyYa9AWT9ZrIGYVLYggVrRn6elDBOxxRhC1ttztNIxhyo6enBZdltf7k+PpqsV0K31szY1SUSlYc2qOUxqu3TPeXsO+GUxqWHzMNdDGXXzKLxLjIBfNP4z0qMHt7RQkWujHZjVBI8v5t9B1CIt8WRwQCoCWA3eZX6hsdKwYffstx2RaxTgk8xxA7eU8pd6V/CvXgZtsimgerCGiTO0WpwAimsD4si2ce/6Cz83Qb2WNXSRCFyf4fHj8ZBqU5y2usk7SKTSvtgk1wcO0T0WSmc2aqwfVAmW3cl6piQBFsqdWFULph7PqxUqsgp4ufrIuZazODYaXmtPmW3ivQ4WCMX7R7bBQ+hL1Tg5wnm7Vt0zVz8KVyP1rQ3EhlyqLEMlombBsHlooezwFfIYU+nWb0CFNowrZe22MNyIOFtCQ8b0iP9+8y4W4DMfw3wjiH6tqUZOcW6gWxM0hbVFNtY8ik8KTOubMuizLIMBxzHaZI4Idx1qfmg2FI2X4ILvremflLvTWopEb/NsAviK69rtFib+fuI3XtZO6EjAEA5RBsAsjViTlMng0MKcx3nbuPQr8kag3szTYHVWa3Mfrh/a4jxPuGv4fbKZY2 ecJUnh9E Nv1Aiwkgerf2Gm/wgIzf3WYl4/n4uZmRl4x+ieb01oYe5rY7voklPgbCocv2S9dyVpJG9N8yb/sJj7DdZUyoLsMN5Tke8qdLXzhPbVW2c4fpg3/db+dadXoyzZpFVUVGVn/nqjxaZb6rWTtoHtwmUBbbCXYEvQSWt4MdZ/vh8yTtimF2cLfmAOgWwPPOkcDvJUcmECUH0dBzK2DFuaiAwerFad6OTTGsubsJy0ieaVLL6o1xfm9Z75a9AwC9jFP4KMvMxXmXchdtIvC68ZftgaUoYZw== 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: On Sat 25-03-23 09:38:12, Mike Rapoport wrote: > On Fri, Mar 24, 2023 at 09:37:31AM +0100, Michal Hocko wrote: > > On Wed 08-03-23 11:41:02, Mike Rapoport wrote: > > > From: "Mike Rapoport (IBM)" > > > > > > When set_memory or set_direct_map APIs used to change attribute or > > > permissions for chunks of several pages, the large PMD that maps these > > > pages in the direct map must be split. Fragmenting the direct map in such > > > manner causes TLB pressure and, eventually, performance degradation. > > > > > > To avoid excessive direct map fragmentation, add ability to allocate > > > "unmapped" pages with __GFP_UNMAPPED flag that will cause removal of the > > > allocated pages from the direct map and use a cache of the unmapped pages. > > > > > > This cache is replenished with higher order pages with preference for > > > PMD_SIZE pages when possible so that there will be fewer splits of large > > > pages in the direct map. > > > > > > The cache is implemented as a buddy allocator, so it can serve high order > > > allocations of unmapped pages. > > > > Why do we need a dedicated gfp flag for all this when a dedicated > > allocator is used anyway. What prevents users to call unmapped_pages_{alloc,free}? > > Using unmapped_pages_{alloc,free} adds complexity to the users which IMO > outweighs the cost of a dedicated gfp flag. Aren't those users rare and very special anyway? > For modules we'd have to make x86::module_{alloc,free}() take care of > mapping and unmapping the allocated pages in the modules virtual address > range. This also might become relevant for another architectures in future > and than we'll have several complex module_alloc()s. The module_alloc use is lacking any justification. More context would be more than useful. Also vmalloc support for the proposed __GFP_UNMAPPED likely needs more explanation as well. > And for secretmem while using unmapped_pages_alloc() is easy, the free path > becomes really complex because actual page freeing for fd-based memory is > deeply buried in the page cache code. Why is that a problem? You already hook into the page freeing path and special case unmapped memory. > My gut feeling is that for PKS using a gfp flag would save a lot of hassle > as well. Well, my take on this is that this is not a generic page allocator functionality. It is clearly an allocator on top of the page allocator. In general gfp flags are scarce and convenience argument usually fires back later on in hard to predict ways. So I've learned to be careful here. I am not saying this is a no-go but right now I do not see any acutal advantage. The vmalloc usecase could be interesting in that regards but it is not really clear to me whether this is a good idea in the first place. -- Michal Hocko SUSE Labs