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 9BB0AC433EF for ; Mon, 18 Apr 2022 10:06:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF3936B0096; Mon, 18 Apr 2022 06:06:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA4088D000E; Mon, 18 Apr 2022 06:06:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C91C06B0099; Mon, 18 Apr 2022 06:06:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id B8D856B0096 for ; Mon, 18 Apr 2022 06:06:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 8F9DD60827 for ; Mon, 18 Apr 2022 10:06:47 +0000 (UTC) X-FDA: 79369570854.05.78CEFCC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id F069C40002 for ; Mon, 18 Apr 2022 10:06:46 +0000 (UTC) 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 3E6EF611B5; 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: X-Rspam-User: X-Rspamd-Queue-Id: F069C40002 X-Stat-Signature: r1d8m8hg1q34gm17p976i93o5yfzoi5f Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Z4OT4i/L"; spf=pass (imf17.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam01 X-HE-Tag: 1650276406-193128 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: 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.