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 0F6E2C433EF for ; Mon, 18 Apr 2022 10:06:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237500AbiDRKJ2 (ORCPT ); Mon, 18 Apr 2022 06:09:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233592AbiDRKJZ (ORCPT ); Mon, 18 Apr 2022 06:09:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A015612612; Mon, 18 Apr 2022 03:06:46 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 3BA45611AF; Mon, 18 Apr 2022 10:06:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65657C385A7; Mon, 18 Apr 2022 10:06:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650276405; bh=uoe2eTNjXAnSgEGbVFQxizx4XBjSzBp1lG6cswI6xbc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z4OT4i/LC2k/i92kWLfFKtTVBpAdJZEhrTM79Ipn6nV/ODqs9njDujOE7UGufhLQE Do/HYbG4P6USOC8UsXPXuco19gPIs7rtCCd0Q3D6LSgvEU++x3yzPanyMqL06a1Fm9 aIIGSGvhWMb31LZbEuWeAEMUSjSc8Mly75z+om044xpunk0PUPohekuF8NmKJW9Rl1 4DywuvNrUFLI25dNnj/mashbTnlGTNXaZkLZHCAnCDWRjavDNqH5NBuxw3m6IIaFWI vgV74FuUatDEOEi5SzMXSz4+aXblqTJNQjcDWglnKZ7EDbpbYmQ0eSH5YgD0p4uul1 B5eHWHALx3iWA== Date: Mon, 18 Apr 2022 13:06:36 +0300 From: Mike Rapoport To: Song Liu Cc: Linus Torvalds , Christoph Hellwig , Luis Chamberlain , Song Liu , bpf , Linux Memory Management List , open list , Alexei Starovoitov , Daniel Borkmann , Kernel Team , Andrew Morton , "Edgecombe, Rick P" , Claudio Imbrenda Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP Message-ID: References: <20220415164413.2727220-1-song@kernel.org> <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Sat, Apr 16, 2022 at 10:26:08PM +0000, Song Liu wrote: > > On Apr 16, 2022, at 1:30 PM, Linus Torvalds wrote: > > > > Maybe I am missing something, but I really don't think this is ready > > for prime-time. We should effectively disable it all, and have people > > think through it a lot more. > > This has been discussed on lwn.net: https://lwn.net/Articles/883454/. > AFAICT, the biggest concern is whether reserving minimal 2MB for BPF > programs is a good trade-off for memory usage. This is again my fault > not to state the motivation clearly: the primary gain comes from less > page table fragmentation and thus better iTLB efficiency. Reserving 2MB pages for BPF programs will indeed reduce the fragmentation, but OTOH it will reduce memory utilization. If for large systems this may not be an issue, on smaller machines trading off memory for iTLB performance may be not that obvious. > Other folks (in recent thread on this topic and offline in other > discussions) also showed strong interests in using similar technical > for text of kernel modules. So I would really like to learn your > opinion on this. There are many details we can optimize, but I guess > the general mechanism has to be something like: > - allocate a huge page, make it safe, and set it as executable; > - as users (BPF, kernel module, etc.) request memory for text, give > a chunk of the huge page to the user. > - use some mechanism to update the chunk of memory safely. There are use-cases that require 4K pages with non-default permissions in the direct map and the pages not necessarily should be executable. There were several suggestions to implement caches of 4K pages backed by 2M pages. I believe that "allocate huge page and split it to basic pages to hand out to users" concept should be implemented at page allocator level and I posted and RFC for this a while ago: https://lore.kernel.org/all/20220127085608.306306-1-rppt@kernel.org/ -- Sincerely yours, Mike.