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 42A81C433F5 for ; Fri, 15 Apr 2022 19:05:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F94E6B0072; Fri, 15 Apr 2022 15:05:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A7296B0073; Fri, 15 Apr 2022 15:05:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 895DC6B0074; Fri, 15 Apr 2022 15:05:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 797F26B0072 for ; Fri, 15 Apr 2022 15:05:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3BAC2250BA for ; Fri, 15 Apr 2022 19:05:45 +0000 (UTC) X-FDA: 79360042650.10.220E504 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf21.hostedemail.com (Postfix) with ESMTP id B85761C0005 for ; Fri, 15 Apr 2022 19:05:44 +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=i8u5wA5pkuMd57YgDKyeRMaeVXySpdGvOCw8eFs9SSc=; b=OBYuj+louCSRCKwtc30JWm58TX pboqz1LXgwQTy6xrbf50VjTba3IocmZv3tNmG4HJYvOu5A0KHOBDQiUiRUYcn/l9yodDX6DycXbdC lBGu2YoYjclbhy5rDDdTXJdq1MLrSGtYrnm/D0hYtkWYxCiogicB96P7HA0AR8ozszUhdtcoIS7rh FbzLjBQ09yGZkdk6Xh3pvDIWmX/mopTEAD+pptDXcG9HYeQgy3SuWELim3D0jiU8abMuHo6QHfT58 z6Gi2tT79cxIqilUN80sNleD3ekeqjCrY3JjbnAo+Lmjvwq6lS/NLzRxsQUWtbBLBaR58iywF3Bs1 +XkwRtJQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nfRGI-00B9lw-E2; Fri, 15 Apr 2022 19:05:42 +0000 Date: Fri, 15 Apr 2022 12:05:42 -0700 From: Luis Chamberlain To: Song Liu Cc: bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, kernel-team@fb.com, akpm@linux-foundation.org, rick.p.edgecombe@intel.com, hch@infradead.org, 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: <20220415164413.2727220-1-song@kernel.org> Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=OBYuj+lo; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf21.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B85761C0005 X-Stat-Signature: 8amom4u8d4x9xtdob1yxm995dbx7xewk X-HE-Tag: 1650049544-873887 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 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. If this goes through v5.19 expect conflicts on modules unless you use modules-testing. Luis