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 9AB80C77B75 for ; Mon, 22 May 2023 22:05:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234531AbjEVWFT (ORCPT ); Mon, 22 May 2023 18:05:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234547AbjEVWFQ (ORCPT ); Mon, 22 May 2023 18:05:16 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 656E4FE for ; Mon, 22 May 2023 15:05:12 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684793109; h=from:from: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; bh=wpJPjBbO36YZsQB1wleZ2Bxu2UdyRVdF2s/GAkF1LgA=; b=f5uM/5MIW0ZkXJ9BPDjgcMNARkDHM2QetrKjkOB1cVAqL7vbg19E6CkXwdoHwQHtTnmHuf or3nmZ8kdIbB9QKEqw5QhRqrNdvP1ToeDz/z25//8J4uppaLJf0Lh8q8Li9RLRTvOXKhHV 8Punl3e6gqtDEAQQlzbGvGV5iptxcJtzq2wO5AqA0FZiqdov0RL51r1XTAFqPbEwOwJYKN 3cavbhBQJP8AxMSA9umnVFXipxHSFpITBZgPOUXTfOwG4hyz7o+UXXKM5rzt6Q79mYtVOO AfSsGOGmmxcy5uEtOma5DHqP5wmaQMwFQtin5g4wPd18/yyfkBFC6JaM6q15ew== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684793109; h=from:from: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; bh=wpJPjBbO36YZsQB1wleZ2Bxu2UdyRVdF2s/GAkF1LgA=; b=oqtmX16LwEasfr+qYEpMoInQ/KL5S5cOZa9a7pH56YdtXnXfrgw5DUgsCI/DNjnyTm+6di xkLcVzBgYHGZRaDQ== To: Song Liu , Mike Rapoport Cc: Kent Overstreet , linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() In-Reply-To: References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> <20230518152354.GD4967@kernel.org> <20230519082945.GE4967@kernel.org> Date: Tue, 23 May 2023 00:05:08 +0200 Message-ID: <878rdgvx7v.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 19 2023 at 08:42, Song Liu wrote: > On Fri, May 19, 2023 at 1:30=E2=80=AFAM Mike Rapoport w= rote: >> What I was thinking is that we can replace module_alloc() calls in your >> allocator with something based on my unmapped_alloc(). If we make the pa= rt >> that refills the cache also take care of creating the mapping in the >> module address space, that should cover everything. > > Here are what I found as I work more on the code: > > 1. It takes quite some work to create a clean interface and make sure > all the users of module_alloc can use the new allocator on all archs. > (archs with text poke need to work with ROX memory from the > allocator; archs without text poke need to have a clean fall back > mechanism, etc.). Most of this work is independent of the actual > allocator, so we can do this part and plug in whatever allocator we > want (buddy+slab or vmap-based or any other solutions). > > 2. vmap_area based solution will work. And it will be one solution for > both < PAGE_SIZE and > PAGE_SIZE allocations. Given > module_alloc is not in any hot path (AFAIK), I don't see any > practical issues with this solution. It will be a little tricky to pl= ace > and name the code, as it uses vmalloc logic, but it is technically a > module allocator. > > I will prioritize building the interface, and migrating users to it. If we > do this part right, changing the underlying allocator should be > straightforward. Correct, that's the only workable approach. Once you have solved #1 the mechanism of the underlying allocator (#2) is pretty much exchangeable. Any attempt to solve #2 before #1 is doomed by definition. Thanks, tglx