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 8FD67C433EF for ; Sat, 16 Apr 2022 01:42:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF1A76B0072; Fri, 15 Apr 2022 21:42:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA0556B0073; Fri, 15 Apr 2022 21:42:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1C556B0074; Fri, 15 Apr 2022 21:42:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id BD72C6B0072 for ; Fri, 15 Apr 2022 21:42:32 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8839525506 for ; Sat, 16 Apr 2022 01:42:32 +0000 (UTC) X-FDA: 79361042544.14.D89AEEF Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf01.hostedemail.com (Postfix) with ESMTP id B827840009 for ; Sat, 16 Apr 2022 01:42:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=bUAJkklJHXouTvJvon6xbqqyKuElapQGuj6PBphCcfo=; b=Xar28tDBlyh51k6qHs4/qv6klW JKgvCYizkt8JvdgPqL/H1j3LkMzhitRPp0hQ0HS6a9NWVvVxTToJjKNkJI7Dyn4yWIPHbqL5glTOM OypgRvApQK3LjTjzi6JSMObnW8ON+wq2JRYUf9KOOtk6/OJMAh77Vv9toU//TkDz/65KgGQBzrs/P fAOhOwvrC+mjeqg4aSRZLMme4Ue6z5bBKOSbhwkdO3f3xMQOA9b23o/z+AUqtaLyHbnLFOxkvvFsn oM7JwAFu8SGO+AVK146Dzu8JrS2izXKe/H42yEiaHvsOuw+P2NyOL6rV3BSXPkGJEMroIniPDimcU 8VWh4f1Q==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfXSF-00BuRc-6s; Sat, 16 Apr 2022 01:42:27 +0000 Date: Fri, 15 Apr 2022 18:42:27 -0700 From: Luis Chamberlain To: Song Liu Cc: bpf , Linux-MM , open list , Alexei Starovoitov , Daniel Borkmann , Kernel Team , Andrew Morton , "Edgecombe, Rick P" , Christoph Hellwig , imbrenda@linux.ibm.com Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP Message-ID: References: <20220415164413.2727220-1-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B827840009 X-Stat-Signature: nbzawoizd64ruyhu7okghq7uhgmycjph Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=Xar28tDB; spf=none (imf01.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-HE-Tag: 1650073351-312238 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 Fri, Apr 15, 2022 at 06:34:16PM -0700, Song Liu wrote: > On Fri, Apr 15, 2022 at 12:05 PM Luis Chamberlain wrote: > > > > On Fri, Apr 15, 2022 at 09:44:09AM -0700, Song Liu wrote: > > > Changes v3 => v4: > > > 1. Fix __weak module_alloc_huge; remove unused vmalloc_huge; rename > > > __vmalloc_huge => vmalloc_huge. (Christoph Hellwig) > > > 2. Use vzalloc (as it was before vmalloc_no_huge) and clean up comments in > > > kvm_s390_pv_alloc_vm. > > > > > > Changes v2 => v3: > > > 1. Use __vmalloc_huge in alloc_large_system_hash. > > > 2. Use EXPORT_SYMBOL_GPL for new functions. (Christoph Hellwig) > > > 3. Add more description about the issues and changes.(Christoph Hellwig, > > > Rick Edgecombe). > > > > > > Changes v1 => v2: > > > 1. Add vmalloc_huge(). (Christoph Hellwig) > > > 2. Add module_alloc_huge(). (Christoph Hellwig) > > > 3. Add Fixes tag and Link tag. (Thorsten Leemhuis) > > > > > > Enabling HAVE_ARCH_HUGE_VMALLOC on x86_64 and use it for bpf_prog_pack has > > > caused some issues [1], as many users of vmalloc are not yet ready to > > > handle huge pages. To enable a more smooth transition to use huge page > > > backed vmalloc memory, this set replaces VM_NO_HUGE_VMAP flag with an new > > > opt-in flag, VM_ALLOW_HUGE_VMAP. More discussions about this topic can be > > > found at [2]. > > > > > > Patch 1 removes VM_NO_HUGE_VMAP and adds VM_ALLOW_HUGE_VMAP. > > > Patch 2 uses VM_ALLOW_HUGE_VMAP in bpf_prog_pack. > > > > > > [1] https://lore.kernel.org/lkml/20220204185742.271030-1-song@kernel.org/ > > > [2] https://lore.kernel.org/linux-mm/20220330225642.1163897-1-song@kernel.org/ > > > > Looks good except for that I think this should just wait for v5.19. The > > fixes are so large I can't see why this needs to be rushed in other than > > the first assumptions of the optimizations had some flaws addressed here. > > We need these changes to fix issues like [3]. Note that there might > still be some > undiscovered issues with huge page backed vmalloc memory on powerpc, which > had HAVE_ARCH_HUGE_VMALLOC enabled since the 5.15 kernel. As we > agreed, the new opt-in flag is a safer approach here. We probably should have > 1/4 and 2/4 back ported to stable. Therefore, I think shipping this > set now would > give us a more reliable 5.18 release. > > Does this make sense? Yes absolutely, but that sounds like that optimization should just be reverted completely from v5.18 isntead then no? Or if one can skip the optimizations for v5.18 with a small patch, and then enable for v5.19. Luis