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 A3B8FC433EF for ; Tue, 12 Apr 2022 04:18:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2CCF6B0071; Tue, 12 Apr 2022 00:18:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB6946B0073; Tue, 12 Apr 2022 00:18:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B57096B0074; Tue, 12 Apr 2022 00:18:28 -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 A03596B0071 for ; Tue, 12 Apr 2022 00:18:28 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6B1AA61A0A for ; Tue, 12 Apr 2022 04:18:28 +0000 (UTC) X-FDA: 79346920296.17.B2C6165 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf25.hostedemail.com (Postfix) with ESMTP id 29F59A0007 for ; Tue, 12 Apr 2022 04:18:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=MAGlAnBxD7wyQSz4EwEMb3ZK13YdG90sRwMHnO/9tbg=; b=ATlnpj6dvccFOr4ecTroAQ+0q0 pqHl6P4OqoGeC+NYqByLkeR1EFVqodIbnCWC1DCWAPhsZKvmubgixvx5GhBFjPB/2pYIdncZBFgQ7 bz64hBsoNwQEEGdPy25CDvNBIp//U4t2Ex+mlSxSS4VQQPsRrhkvowVIdJRsDbWL1fAmxYbncgAFD WXn3jxBWSJSKEMdF7RVJMYJFc9lXYiLVFU01UzQNohPsUyypn2XpNt9tkTJK4vJN9JBX6hEmqTSbD 6Jb9FTrhIzk15DXbp8uxbDfg4i9wIoNie1tvHkw9bBgDxSp1GcNI+WePACCHlmQrX/VLAwY2Qc+tp AR7JTC5A==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ne7yt-00BVqf-8R; Tue, 12 Apr 2022 04:18:19 +0000 Date: Mon, 11 Apr 2022 21:18:19 -0700 From: Christoph Hellwig To: Song Liu Cc: bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, akpm@linux-foundation.org, rick.p.edgecombe@intel.com, hch@infradead.org, imbrenda@linux.ibm.com, mcgrof@kernel.org, Nicholas Piggin Subject: Re: [PATCH v2 bpf 1/3] vmalloc: replace VM_NO_HUGE_VMAP with VM_ALLOW_HUGE_VMAP Message-ID: References: <20220411233549.740157-1-song@kernel.org> <20220411233549.740157-2-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220411233549.740157-2-song@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Stat-Signature: nucn9faswemwkc68pziraq4e9y1enypw Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=ATlnpj6d; spf=none (imf25.hostedemail.com: domain of BATV+ac3e28a1d77c94e338e3+6806+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+ac3e28a1d77c94e338e3+6806+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 29F59A0007 X-HE-Tag: 1649737105-18420 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 11, 2022 at 04:35:46PM -0700, Song Liu wrote: > Huge page backed vmalloc memory could benefit performance in many cases. > Since some users of vmalloc may not be ready to handle huge pages, > VM_NO_HUGE_VMAP was introduced to allow vmalloc users to opt-out huge > pages. However, it is not easy to add VM_NO_HUGE_VMAP to all the users > that may try to allocate >= PMD_SIZE pages, but are not ready to handle > huge pages properly. This is a good place to document what the problems are, and how they are hard to track down (e.g. because the allocations are passed down I/O stacks) > > Replace VM_NO_HUGE_VMAP with an opt-in flag, VM_ALLOW_HUGE_VMAP, so that > users that benefit from huge pages could ask specificially. > > Also, replace vmalloc_no_huge() with opt-in helper vmalloc_huge(). We still need to find out what the primary users of the large vmalloc hashes was and convert them. > +extern void *vmalloc_huge(unsigned long size) __alloc_size(1); No need for the extern. > +EXPORT_SYMBOL(vmalloc_huge); EXPORT_SYMBOL_GPL for all advanced vmalloc functionality, please.