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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2E2ACCA47C for ; Wed, 13 Jul 2022 20:27:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236919AbiGMU10 (ORCPT ); Wed, 13 Jul 2022 16:27:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229604AbiGMU1Z (ORCPT ); Wed, 13 Jul 2022 16:27:25 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D65602D1E8; Wed, 13 Jul 2022 13:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aMwCqCZv7KMm7FPwRBaOPDqNH5Xzn53rKrd3wy7Qd0w=; b=dbi9CHnMFf07cd9TO0b63y6NJ/ EFhxQwRZ5INwn4lK+g3Xz52wZ1Ufh6bit0UjcgJ+ztc/Ic7AFmYpzlaC1rFNuplCSZ9FyeIc3FSXv /4HhcZz6vPKRNDsfkskAQk73c0dCn9m2f/szsziEdotI2rgMKhqvCwQ/hFO26QJf0Tb9M6Ah7mZES S7RHI2AGYAb+v8ebY/6QeatcDMl0i1Hz8UWulpNU0uTHHyrSMTmGxAIwQ7OmYz7F0OvLHwpwU7HHT Gf6+HN8T0OGeF6o9/M5cjr/Ou6QOdPGH6eOvtD2YaVjxbDS2H6SKg+TKN7P75ztpBqrfbWyfIqC1f dAVn1iXg==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=worktop.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBiwR-003er4-6q; Wed, 13 Jul 2022 20:26:39 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 50F5D980082; Wed, 13 Jul 2022 22:26:37 +0200 (CEST) Date: Wed, 13 Jul 2022 22:26:37 +0200 From: Peter Zijlstra To: Song Liu Cc: Song Liu , bpf , lkml , Linux-MM , "linux-modules@vger.kernel.org" , Luis Chamberlain , Steven Rostedt , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Masami Hiramatsu , "naveen.n.rao@linux.ibm.com" , "davem@davemloft.net" , "anil.s.keshavamurthy@intel.com" , "keescook@chromium.org" , "hch@infradead.org" , "dave@stgolabs.net" , "daniel@iogearbox.net" , Kernel Team , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "rick.p.edgecombe@intel.com" , "akpm@linux-foundation.org" Subject: Re: [PATCH bpf-next 1/3] mm/vmalloc: introduce vmalloc_exec which allocates RO+X memory Message-ID: References: <20220713071846.3286727-1-song@kernel.org> <20220713071846.3286727-2-song@kernel.org> <7C927986-3665-4BD6-A339-D3FE4A71E3D4@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C927986-3665-4BD6-A339-D3FE4A71E3D4@fb.com> Precedence: bulk List-ID: On Wed, Jul 13, 2022 at 03:48:35PM +0000, Song Liu wrote: > > So how about instead we separate them? Then much of the problem goes > > away, you don't need to track these 2M chunks at all. > > If we manage the memory in < 2MiB granularity, either 4kB or smaller, > we still need some way to track which parts are being used, no? I mean > the bitmap. I was thinking the vmalloc vmap_area tree could help out there.