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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBB11C433EF for ; Thu, 21 Apr 2022 06:09:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384682AbiDUGMY (ORCPT ); Thu, 21 Apr 2022 02:12:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353216AbiDUGMW (ORCPT ); Thu, 21 Apr 2022 02:12:22 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 617C912AEA for ; Wed, 20 Apr 2022 23:09:33 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id b24so5104781edu.10 for ; Wed, 20 Apr 2022 23:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVUWs35f4WE+aWC7FcpSq4pfrFchzLzCfgbNdTOWfy8=; b=VBqyRxaQG527a7fx7AgAznM8UUHxBASgzvSF4gmMRD4VYJdHUiSNVoPhgu42LoOYtS y6gPAHVOwwUd483vHIRxh7hbgdA8HsUg/bgP6y7Dqxs90ng2yo25hED4GNEKdgjsdXXY mUFQ/gnQ78Lay0jv9vKeHJr4kI/tgiaSFRcic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVUWs35f4WE+aWC7FcpSq4pfrFchzLzCfgbNdTOWfy8=; b=bYcQedTDAcWnAxzEecRfYSMvusVJys6ireJaWVv31DD0RuaqEfe6EMZry9LIfnZ/lc 9X4fd7X6nI7SQh4gJlGralfJoOiIJOwydTMQv7YXEEFiDEJsG2Fmqv+6Bn7L0CLDRrcO vQOqWGdGJE+uzQ31it9l3Kiayx/GBgAc4IpJTQ6FCNOEZVRhjwnVWV1ttSdIokhg/DOv y2kINdiN7OeEmwCzfWNmK61MOmuWp5yQfZodoIWDRWonwd0WiISOfry9Gf/zQ6pSWixt IAR6ZDGE/hmH9IGa318vlMhmoxAf7aw6heqLTCrxfiKhPCHdpw53Tp/Src6fc9nC+7uu DEJQ== X-Gm-Message-State: AOAM533A2izLISlG1jH96M7uLCkIAwCOzrUn1HR5YwD+MJAfAEZxNINc jZB2oP6Xoeuq7bqvMsvLBHhrFU9Nuk0CipmJC24= X-Google-Smtp-Source: ABdhPJxrDi2VihTHvBqqL5gHrCQEbtCTb/zlZpfNLHw9DGDo86kQC5o64fFg1yuv8dVemhZypDybvA== X-Received: by 2002:a05:6402:3551:b0:423:f55d:46ab with SMTP id f17-20020a056402355100b00423f55d46abmr16495546edd.384.1650521371563; Wed, 20 Apr 2022 23:09:31 -0700 (PDT) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com. [209.85.208.54]) by smtp.gmail.com with ESMTPSA id j8-20020a170906278800b006f01fd64de0sm236977ejc.103.2022.04.20.23.09.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Apr 2022 23:09:31 -0700 (PDT) Received: by mail-ed1-f54.google.com with SMTP id z99so5122312ede.5 for ; Wed, 20 Apr 2022 23:09:30 -0700 (PDT) X-Received: by 2002:a2e:91d9:0:b0:24d:c221:4941 with SMTP id u25-20020a2e91d9000000b0024dc2214941mr9547564ljg.164.1650520984267; Wed, 20 Apr 2022 23:03:04 -0700 (PDT) MIME-Version: 1.0 References: <20220415164413.2727220-1-song@kernel.org> <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com> <88eafc9220d134d72db9eb381114432e71903022.camel@intel.com> <1650511496.iys9nxdueb.astroid@bobo.none> In-Reply-To: From: Linus Torvalds Date: Wed, 20 Apr 2022 23:02:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP To: Nicholas Piggin Cc: Mike Rapoport , "akpm@linux-foundation.org" , "ast@kernel.org" , "bp@alien8.de" , "bpf@vger.kernel.org" , "daniel@iogearbox.net" , "dborkman@redhat.com" , "edumazet@google.com" , "hch@infradead.org" , "hpa@zytor.com" , "imbrenda@linux.ibm.com" , Kernel Team , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "mbenes@suse.cz" , "mcgrof@kernel.org" , "pmladek@suse.com" , "Edgecombe, Rick P" , "song@kernel.org" , Song Liu Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 20, 2022 at 10:48 PM Linus Torvalds wrote: > > The lagepage thing needs to be opt-in, and needs a lot more care. Side note: part of the opt-in really should be about the performance impact. It clearly can be quite noticeable, as outlined by that powerpc case in commit 8abddd968a30 ("powerpc/64s/radix: Enable huge vmalloc mappings"), but it presumably is some _particular_ case that actually matters. But it's equalyl clearly not the module code/data case, since __module_alloc() explicitly disables largepages on powerpc. At a guess, it's one or more of the large hash-table allocations. And it would actually be interesting to hear *which*one*. From the 'git diff' workload, I'd expect it to be the dentry lookup hash table - I can't think of anything else that would be vmalloc'ed that would be remotely interesting - but who knows. So I think the whole "opt in" isn't _purely_ about the "oh, random cases are broken for odd reasons, so let's not enable it by default". I think it would actually be good to literally mark the cases that matter (and have the performance numbers for those cases). Linus