From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bpf-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id CBE45C433F5
	for <bpf@archiver.kernel.org>; Sat,  9 Apr 2022 05:28:15 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S231948AbiDIFaT (ORCPT <rfc822;bpf@archiver.kernel.org>);
        Sat, 9 Apr 2022 01:30:19 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49366 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S230030AbiDIFaS (ORCPT <rfc822;bpf@vger.kernel.org>);
        Sat, 9 Apr 2022 01:30:18 -0400
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0696826544;
        Fri,  8 Apr 2022 22:28:12 -0700 (PDT)
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=UELACyVvvsv7I05n9+vrbyhbff2QK+RQVjTLcZ7BmLg=; b=yjRyUNNZJ+QcVl6cC7NuMHkkWo
        s0/WGg7fW8quqrK5WTwAxvCspJlWPhWh44WOnhXrUs6Xj9sc4KmSWjbFQvLmqLuDYlrXkfni5q9nc
        IX7lbqve87N0Wlia2y6UmXmDfnF5/aZ7W2DmAvELSS1I7W6UMjD9Aii0ET81eszLt80eQMGz0VPKT
        0X715mDCiAtLZFok6yq8NE1kX7ORTM2aySTyp6Zg6sy59MUm61MITFQ4DlOmrpEA0nW8A9e0Q+m/W
        Nq7p0DjvUlc6TBotYnplOKXKIBP7sIzbqgKKmC/PooxRmDPdope8lHBakiuly2QhtoUedRmzaSmiG
        ZNKutwGA==;
Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux))
        id 1nd3dq-002IuG-Ht; Sat, 09 Apr 2022 05:28:10 +0000
Date:   Fri, 8 Apr 2022 22:28:10 -0700
From:   Christoph Hellwig <hch@infradead.org>
To:     Song Liu <song@kernel.org>
Cc:     bpf@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org,
        ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
        kernel-team@fb.com, akpm@linux-foundation.org,
        rick.p.edgecombe@intel.com, hch@infradead.org,
        imbrenda@linux.ibm.com
Subject: Re: [PATCH bpf 1/2] vmalloc: replace VM_NO_HUGE_VMAP with
 VM_ALLOW_HUGE_VMAP
Message-ID: <YlEZahPCTI/qh/6u@infradead.org>
References: <20220408223443.3303509-1-song@kernel.org>
 <20220408223443.3303509-2-song@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220408223443.3303509-2-song@kernel.org>
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Precedence: bulk
List-ID: <bpf.vger.kernel.org>
X-Mailing-List: bpf@vger.kernel.org

On Fri, Apr 08, 2022 at 03:34:42PM -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.
> 
> 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.

Given that the huge page backing was added explicitly for some big boot
time allocated hashed,those should probably have the VM_ALLOW_HUGE_VMAP
added from the start (maybe not in this patch, but certainly in this
series).  We'll probably also need a vmalloc_huge interface for those.