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 4E888C76196 for ; Tue, 28 Mar 2023 15:24:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDF996B0074; Tue, 28 Mar 2023 11:24:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C84376B0072; Tue, 28 Mar 2023 11:24:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4C806B0074; Tue, 28 Mar 2023 11:24:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A18F66B0071 for ; Tue, 28 Mar 2023 11:24:54 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7550DABE63 for ; Tue, 28 Mar 2023 15:24:54 +0000 (UTC) X-FDA: 80618679708.06.50EA12B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf06.hostedemail.com (Postfix) with ESMTP id 773E3180003 for ; Tue, 28 Mar 2023 15:24:51 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="d/ox4Hsy"; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1680017091; 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=jboALtBYOng+vAI1cXsw10gaHCTV6EGfJuMtn5T9qYU=; b=0fspI2RWW2R4Ssb+rJJ9VgW9O5MzfGf1iuNOLTbyjtqhhOZF3mRnbxvzskPmN7dRksMVrm VXE7VRv34EJpfmuvWv8YN6f5Q9isk63fS/42snMYsmLHcbB7dvKIXENan5Vk2M3zBwlUmS lqSTqjxJ453DQu9mRtZN6x9R/wz1mlw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="d/ox4Hsy"; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1680017091; a=rsa-sha256; cv=none; b=lS9wAIcv12ZsM5gXLnDoPOj69Pw2EET3n1hw6AdOxmNkYWq9rrz6BY5dsYjF0y5qtzWgAM HYS3be3DRCI62pAUMvEMD/r30EGG7I9/NxUqskxLxAK3RmXpAhtF4/IZhAGunVjVRLhCN9 3DJm2xLRsNZypqLYlk2IGNaeDA1y1h8= 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-out1.suse.de (Postfix) with ESMTPS id D0283219DA; Tue, 28 Mar 2023 15:24:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1680017089; 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=jboALtBYOng+vAI1cXsw10gaHCTV6EGfJuMtn5T9qYU=; b=d/ox4Hsy51Ysq4Z8utOZ85kAr07ayerlZVJleL9GXKEGNpyGiI+K9D1AQnhyp1oPpiC6eq m8ycCh5pFCECGHJaL4ixLL7RrLW4D1oM9byutuS7V1UWrNfxyzxbP8MbtuPPVVqcdIo8MD VBG3mbJ61PWiEZNxANCT/hHgzFz01Ek= 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 B53951390D; Tue, 28 Mar 2023 15:24:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 5pJ4KcEGI2SjGQAAMHmgww (envelope-from ); Tue, 28 Mar 2023 15:24:49 +0000 Date: Tue, 28 Mar 2023 17:24:49 +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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 773E3180003 X-Rspam-User: X-Stat-Signature: p9ggtkc3fs8e8g6aqdh63if484xsofpg X-HE-Tag: 1680017091-351880 X-HE-Meta: U2FsdGVkX18dq6bn5c+y4v+3gcj92z/xBFrRTZU7qoBBRgd9RPvtupBu2/GWenjR/o8qdzsVn2gaZSJMTMO2ubRBNuS+ogMEnX0QU7s2/WEhfpYTL9a8VysOowk1I/okhiYvUKp4zD50sMq6JfOsLIZg6Nn6Ek3PkpkQoRA/u4iW5gEjWKqZaWPOeV/wl6RyC6XQwg7BR+dg/uUdeqw34Dur9nEht+wYn1IK/y4qFXi39UUSvs+eUopXgkQ91//PVbPCfUh72pKahsP8Zj5Zg5hv2x94zUe4DoS13xvBOZ36Pqd1GmPareHl/kZ2CzX25/uWRgL1ELtbCSYL6Q7pSnPtr/Uum3UEr7Lt45AJtrnQLyySE5bdAl0q+4M3fOa6N5AiZRqzE8RQwitAsNzhDCBptlG2HzF7zuDXw2wgnxWtGZ1pwOn9iLLtJ9AJhtDqj8Vz6Sl0l/0z4VZ6m2QyCOTMeGv8xBMGO/xN38UCihjuLeV+rn6/BIcQ3eiBZkP6qwU3k0Z4Hx7NFy8DXieV9/gBI151HwHDX6MBjtbdgoxH9VCoxeRjcL98oE0Zh0mxt0CNs6BDw9YWJEPzrte9ze4lvXgRkfji7DmXQKfQwlDVmC3tV+aqYNsUbhlrWeY8QZHdgiWvoilKl2er/EnY+yF0andmJC7pLcf5sc0+SJyQRaVPWGelaXVfu90XOKPny63r9/YbbDZkbTJegJ2LlagF+zVPQ6BmRZFA4XeHck2r3NkEo0LWtc9N6d80gPs+ISlcjQDsQHGfcqi3z21As9geUX2wpNYAUcTcxbA9hJLIKQYhGTxvi5q3mIfBr/tSYrCGEvunBVs6AqApBKGByxi8CJatOFpmWQGgODvPKxk/vXMeqgGrXF+CWE1v7LksYPVqSagciNDCk0cf2zmOAFlO7iQ7Phl+90I6qFaKSbl75mPXlNK3M0LWmwzGX5VP1HFbRrSIimXkUnmc68N L1URDRPg 9bLNWIy2hOmlm+esOC2+yFrbg+N22R9lHS5PX3X/5sdVyzZc4bY9MI4HzoGzB0PygPI/SyjRfeiYSu1w4vhbF4rduMCHXTirmOfXdmvrxdsneGGRiulctQSZmRTIxHXPy4INW/+Tg0Gx3hTjQB/r9lCVzUo0ekoDhYRRAvV60/G+PRVsU6eSKwnikwQINc0hhfBrfweMxqEH0JvIx6+ln+XmAow6T9jr8dnWRO1SL3E5srInvo8IF04yHkPwiAPTB+qjv87J0sHYXIGs8bXq+Ka6IA+NqIWu3ysYpIPDEmChNWn0= 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 Tue 28-03-23 18:11:20, Mike Rapoport wrote: > On Tue, Mar 28, 2023 at 09:39:37AM +0200, Michal Hocko wrote: [...] > > OK, so you want to reduce that direct map fragmentation? > > Yes. > > > Is that a real problem? > > A while ago Intel folks published report [1] that showed better performance > with large pages in the direct map for majority of benchmarks. > > > My impression is that modules are mostly static thing. BPF > > might be a different thing though. I have a recollection that BPF guys > > were dealing with direct map fragmention as well. > > Modules are indeed static, but module_alloc() used by anything that > allocates code pages, e.g. kprobes, ftrace and BPF. Besides, Thomas > mentioned that having code in 2M pages reduces iTLB pressure [2], but > that's not only about avoiding the splits in the direct map but also about > using large mappings in the modules address space. > > BPF guys suggested an allocator for executable memory [3] mainly because > they've seen performance improvement of 0.6% - 0.9% in their setups [4]. These are fair arguments and it would have been better to have them in the RFC. Also it is not really clear to me what is the actual benefit of the unmapping for those usecases. I do get they want to benefit from caching on the same permission setup but do they need unmapping as well? > > > If we were to use unmapped_pages_alloc() in modules_alloc(), we would have > > > to implement the part of vmalloc() that reserves the virtual addresses and > > > maps the allocated memory there in module_alloc(). > > > > Another option would be to provide an allocator for the backing pages to > > vmalloc. But I do agree that a gfp flag is a less laborous way to > > achieve the same. So the primary question really is whether we really > > need vmalloc support for unmapped memory. > > I'm not sure I follow here. module_alloc() is essentially an alias to > vmalloc(), so to reduce direct map fragmentation caused by code allocations > the most sensible way IMO is to support unmapped memory in vmalloc(). What I meant to say is that vmalloc is currently using the page allocator (resp bulk allocator) for the backing storage. I can imagine an extension to replace this default allocator by something else (e.g. a given allocation function). This would be more generic and it would allow different usecases (e.g. benefit from caching withtout doing the actual unmapping). > I also think vmalloc with unmmapped pages can provide backing pages for > execmem_alloc() Song proposed. Why would you need to have execmem_alloc have its memory virtually mapped into vmalloc space? > [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/ > [2] https://lore.kernel.org/all/87mt86rbvy.ffs@tglx/ > [3] https://lore.kernel.org/all/20221107223921.3451913-1-song@kernel.org/ > [4] https://lore.kernel.org/bpf/20220707223546.4124919-1-song@kernel.org/ > > -- > Sincerely yours, > Mike. -- Michal Hocko SUSE Labs