Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1016745pxb; Fri, 15 Apr 2022 18:28:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxooCXLEUunF++tPFQdlJYtYuA96IdK3pvvtS8bEIGJ9LsmYjprYwhGKncmZ73+mt5Zf4uU X-Received: by 2002:a62:1714:0:b0:505:fbff:fe8e with SMTP id 20-20020a621714000000b00505fbfffe8emr1477471pfx.49.1650072489693; Fri, 15 Apr 2022 18:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650072489; cv=none; d=google.com; s=arc-20160816; b=g+hFej5vkQDbw7PMwYCMjqZUaE30N1AI7abjUWrF2yunVlld0k/EaU5Wbe9uV+CX/k 40oW6VD3dLF385Fwomuoigb89gQFC15KipAwawhI5HiZRj/DqoeFKooSDV9iqhdrN/uD kTdc9i9G3jw28cuzFaCowlMd2wHC2uP+V7y8G+QCW7jDxCT8+dwTJtCEcl4MYe+hTub3 7iUeq+JCAI0Vz4A9phhum3goJiM1yP44Pw32BSjPcbATVa6j5+KeZT7p66mB0rH/60gY LEYltja/yhBe3KEitfyvIf/GT/unFonEd52J/YEbyybkzTt+w+jq8rMPj1pRgyeZnGxN mLzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=i8u5wA5pkuMd57YgDKyeRMaeVXySpdGvOCw8eFs9SSc=; b=bbwSQRVrleFurRX0EEeM+FUlwiqYIDGOHPvTAplXZ4ww8gSl1GxG37T2FvT/1Byx2k cNALAx8AaLr5GCFNchZAENly0e8xQwrcv1RiNvtbkDXqHWCJESm8I6qV+K7Y3FGebss3 S99dJFs7qIq8jvGPPXbaNR1cx71TlY61Pw9Fl68TvaNbyDg3/gPyAvSpDx3lzn5YMz8j GCoUa/U32H0CGAMjKMX5bIaYY1t2K9XNtw3FTq8En0/faHVUSJUBMHGftuPKrTXFa0dN dUpLqr3M4EGDP0/BRfrI/w8bK9IV2TLykFG6yRVqYlfpNHxhJCfcD+Z85VdehEdtBJkN BBkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=OBYuj+lo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id om8-20020a17090b3a8800b001bd14e030c7si3349203pjb.159.2022.04.15.18.28.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:28:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=OBYuj+lo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E410D14344F; Fri, 15 Apr 2022 17:58:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348124AbiDOTIM (ORCPT + 99 others); Fri, 15 Apr 2022 15:08:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347893AbiDOTIL (ORCPT ); Fri, 15 Apr 2022 15:08:11 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 263C93A5F5; Fri, 15 Apr 2022 12:05:43 -0700 (PDT) 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> Sender: Luis Chamberlain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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