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 CBC4CC433F5 for ; Tue, 19 Apr 2022 18:21:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32C9D6B0074; Tue, 19 Apr 2022 14:21:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DB876B0075; Tue, 19 Apr 2022 14:21:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17D486B0078; Tue, 19 Apr 2022 14:21:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 09D6D6B0074 for ; Tue, 19 Apr 2022 14:21:04 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CD4CB250AB for ; Tue, 19 Apr 2022 18:21:03 +0000 (UTC) X-FDA: 79374445206.16.FEA18CD Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf09.hostedemail.com (Postfix) with ESMTP id 4737B140010 for ; Tue, 19 Apr 2022 18:21:02 +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 ams.source.kernel.org (Postfix) with ESMTPS id 901A0B818E0; Tue, 19 Apr 2022 18:21:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5ABDC385A7; Tue, 19 Apr 2022 18:20:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650392460; bh=8AeBQCwCgx6CBpKhjtWJeO2vlioukw/vzb3Wc0XyEJU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BBiPFR2Cp9zcXQ5jKHDOCxzVXcuw2w+gtyx5lfsC8dzJL29YWieLmaKgOVFZLzH30 Z3egiTZcCgC/BFdcP9Hy7wOkD3gvIH+Th925MxsKl3nsT2Bt9yFKEGiqGGY6ezRe9u Gtz9LIZnRahmwTsNUZQObRjw4tke+VK9PKXBzVSteHqOTarOrOyo2Z7Y5V5x0+6Mq4 V/hgr5hRgrK/vvLMli0UbDpOpR0CI7sZA9EYe1kZbxltmdM8rPbq0DcVKF0tvM7dzK kWSky2nU2wQWA6PbwU4kq8i9CJXFbjKT0omwD2t6mB2NdtBNRjwECmjyB79h9X+jl9 XUhtQtehx8HBA== Date: Tue, 19 Apr 2022 21:20:48 +0300 From: Mike Rapoport To: Luis Chamberlain Cc: Song Liu , Linus Torvalds , Christoph Hellwig , Song Liu , bpf , Linux Memory Management List , open list , Alexei Starovoitov , Daniel Borkmann , Kernel Team , Andrew Morton , "Edgecombe, Rick P" , Claudio Imbrenda , Borislav Petkov , Petr Mladek , Miroslav Benes , Eric Dumazet , Daniel Borkmann , "H. Peter Anvin" 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-Server: rspam03 X-Rspamd-Queue-Id: 4737B140010 X-Stat-Signature: jitgzz3h4tzbbhdyapy1ebx4nnz4r3k7 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BBiPFR2C; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org X-HE-Tag: 1650392462-843236 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 Mon, Apr 18, 2022 at 05:44:19PM -0700, Luis Chamberlain wrote: > On Mon, Apr 18, 2022 at 01:06:36PM +0300, Mike Rapoport wrote: > > 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. > > So the current optimization at best should be a kconfig option? Maybe not and it'll be fine on smaller systems, but from what I see the bpf_prog_pack implementation didn't consider them. And if we move the caches from BPF to vmalloc or page allocator that would be much less of an issue. > > 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/ > > Neat, so although eBPF is a big user, are there some use cases outside > that immediately benefit? Anything that uses set_memory APIs could benefit from this. Except eBPF and other module_alloc() users, there is secretmem that also fractures the direct map and actually that was my initial use case for these patches. Another possible use-case can be protection of page tables with PKS: https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@intel.com/ Vlastimil also mentioned that SEV-SNP could use such caching mechanism, but I don't know the details. > LUis -- Sincerely yours, Mike.