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 9530BC64EC4 for ; Thu, 9 Mar 2023 15:28:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0AAE6B0072; Thu, 9 Mar 2023 10:28:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB82B280002; Thu, 9 Mar 2023 10:28:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7F34280001; Thu, 9 Mar 2023 10:28:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B8EE26B0072 for ; Thu, 9 Mar 2023 10:28:08 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 218291210E9 for ; Thu, 9 Mar 2023 15:28:08 +0000 (UTC) X-FDA: 80549740656.26.D61295F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf01.hostedemail.com (Postfix) with ESMTP id AEB39400D3 for ; Thu, 9 Mar 2023 15:27:23 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LVulMktl; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678375643; 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=hy2o74vioA09e9wXZs6fGma/+BaTqAL0y1QblDGhhLY=; b=O1pcFyJnKevlX2O/WMVv8POCg9M8tho2JLa8v/w0NPp0NFhbxNhk+krX4r/ZyR44zpp2c5 y9XR3OQDBhXtyuuSH79103mN+0ZUQdyIHNVVBLNAuuFVlG4lWtAWePmN+UMN3sORbacTMJ bpEycMwBL5HBOiTMunPddtR/kH9GEtM= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LVulMktl; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678375643; a=rsa-sha256; cv=none; b=2R0EXFndR9YHBAoqbDy11SdYAW8FSJkUN2/C92an3guoIozxep/hsI5Y/xsR8Dnyj1PFdA Soig+krNzCJi1MXw0P+TFSJ4N0m7D7YXduuAUPeHgvnzHrCPXMM7+wrn7wWWH9bqO9k6u3 vfX6KjfHZgYoBt8JVj7COygBxCzKhmA= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E3A3EB81F81; Thu, 9 Mar 2023 15:27:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96BCAC433EF; Thu, 9 Mar 2023 15:27:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678375640; bh=jsK3tmby10Zy34nLJCJxkX/QS4loLNlyWVZ4G9+hhRU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LVulMktlIRbvD/FGHqyjw1/jbFDRkwJZgvCV11hU6NBtOVxLBeZDeqRKbet2/TFjS hxphOdBXISNO1uf4TcGzLLMR9xQT6rbqLwybzqSdyxyItxup0LBS5G3n9MOQyIxwa2 jRRN5CZaVpK7L4JGc2hR/pwlQr9R8qmeX30rH7g135lFYd2twFV3unkEMwG12p7uSA ZV9dExQJ1HMeyH7ePsuillYdxJQw+zuAPI+n5YPQ3S6D9r7zh9r5uGrAInnQ28ObUG JhXWxxQhHGgVIl1+xx5m9pkNJoRjhniZPZPc+GQWeUmwzFnavDCxnsalrWIWUv6RW6 Du+wmFGEseflQ== Date: Thu, 9 Mar 2023 17:27:06 +0200 From: Mike Rapoport To: Hyeonggon Yoo <42.hyeyoo@gmail.com> 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: rspam02 X-Rspamd-Queue-Id: AEB39400D3 X-Stat-Signature: w419ht71npwizc6eyr85c8q7chaf4bxs X-HE-Tag: 1678375643-781521 X-HE-Meta: U2FsdGVkX196lacwUULygWaMqjWCnlGbGE/9psWQEbhu1qKts3rLAqSr2bTWEXLp33oROOORdBQZPxcLGrmnmwZ7nooROrfMs2TaSTdwK0gC3s/CUOjUeern48wlXJENnyvD7yhO8n7qANv9ocQU+kvadAsPmGTImf91j4WDAeOAvSe3JROPk3ig1LPZNNW9SNu+j13N4cwxS1OrDLkNTQ9kSyPNJcAtLESrQxUAu02kZqr276lI1IjKefLPUBpTGt2fMrefFDvetbXC+GY9OzK25vsNjMJY0+oPs1adw4aMcJcjj7TWwABXMZI4NEJB64mnIHsZjYBuNdwLZGAB8bRkC7O2095j8qvKWTKuCxpJyK1pebgcnGT/xKQxDrfyMOQBK2yDtBnhGa6oD08MU0RZGtyhkW6pAGaKcrwfBFZLfomi2XiIz5j+b6xRA2sJ96votXzyZ1RtbxUuvP8yzLHakjb1SfJmo07rA3o71XMGwJObrLcCQKqbKTL2vEGcnRji0CZPyEhccmyFYqZHOt0Lzldu4BSlYI14RReHk51GZF9KasrBPR3m3lYX8l9GvVMKUFXjZjr/zABkOD8hu5thjXCijDepL6cVeCcv77VI7wjW+03uIEk+0c+cLuWIyb5EunjROEgebXirua27qSJfW989lBhn8HcdJg1zwN45wzsjESMNexn5/VWMT3wPfeVVFLMgnKrUsM19Q2/tHebY8IMBXTcW+1HHqiA0Xk+sk/IlYSw/90Pb64B887+hnDidomP2npL19kanS05h/qpDiaHiQEoqoEYuhd1jlJv+USpPkQlaFC+ZKNoA6mltAWhHPypEVpxh5keaNF2xSHFw05oZSZrORKPSB+Q2uAtlBwbpraZsDF5QCb+XHghzQ9/oc3WIKNvnMP+9C2o442WYrvvMXr8PF9YqlE2xt+NiDVUqwaT0asNe0isEmgptDJqJ3tFyCc+nZ98ICZq Fl5D7SMi hh2EIdj1V03ysND5O2BOk6mbXblQgfZXSdivq2EeMuADEnIzrpu5mjHORNCnI97qlmkH/a0cDsAoIKkXWYCOCcV0qOMPlH5y4Io0HWt7PIGXZOYSSi0dYZ/17LsovxyA+2oQE5PpD+KVtK6UADmKdSj4Up87MNG/XI5cgwV2qmYLeliaNHaich9i35Jivf+Qff98nnXfuFeDbaWeqYWSaiuy33xgmD58yA/8mZZpx43e9Dq42j52M3RlCyV2+zvV1lEG5JANvJ1lbMSnH6BmveliDq1DVrYebJFzQu1BkpgBzHFkjqMTOnex/F9ybyrdd5toSQzs7G2BacnKmWQZvFFkSg3Ki7h3E1BqmZFQy616H0zajvQ3t6Yq6prHDbsCyhW2GGAHPS+V2YrgKgIcLHsNvrzrCMTfMIIo6cNYJdENGSa0LEPl8B80VFoY5LTsXNt9xcpjRb8B/0J9uzVdBgJq+JLCx3elK8rdZ 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 Thu, Mar 09, 2023 at 06:31:25AM +0000, Hyeonggon Yoo wrote: > On Wed, Mar 08, 2023 at 11:41:02AM +0200, 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. > > Hello, > > To me it seems unnecessary to increase pageblock bitmap size just to > distinguish if it is allocated with __GFP_UNMAPPED. > > I think this can be implemented as an independent cache on top of > buddy allocator, and introducing new API for unmapped page > allocation and freeing? Yes, it could. But with such API we'd also need to take care of mapping/unmapping these pages for the modules use case which is not that difficult, but still more complex than a flag to vmalloc(). As for secretmem, freeing of secretmem pages happens in the page cache, so changing that to use, say, unmapped_free() would be quite intrusive. Another reason to mark the entire pageblock as unmapped is possibility to steal pages from that pageblock into the unmmaped cache when they become free. When we allocate pages to replenish the unmapped cache, we split the large mapping in the direct map, so even the pages in the same pageblock that do not get into the cache are still mapped at PTE level. When they are freed, they will be put in the cache and so fewer explicit cache refills that split the large mappings will be required. > Thanks, > Hyeonggon -- Sincerely yours, Mike.