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 F109DC433EF for ; Thu, 21 Apr 2022 08:57:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88E506B0071; Thu, 21 Apr 2022 04:57:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 83CCB6B0073; Thu, 21 Apr 2022 04:57:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72BCA6B0074; Thu, 21 Apr 2022 04:57:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 5FA546B0071 for ; Thu, 21 Apr 2022 04:57:30 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2DD66216F5 for ; Thu, 21 Apr 2022 08:57:30 +0000 (UTC) X-FDA: 79380282660.16.020A8A6 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 423A840022 for ; Thu, 21 Apr 2022 08:57:29 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id mp16-20020a17090b191000b001cb5efbcab6so7164124pjb.4 for ; Thu, 21 Apr 2022 01:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=ylxB+Hx++LEIgDce19t2otGtYWyC/YHt80P7LQP09MU=; b=TI7S5wZtKMPdTN+iqX/9T9mPd79QQeOPulqS2EsJogc0+YqvElchYQCQuy0DXbdlNU /EY4iGvqIXVy8t0kZ4PUPcM97/9A31L83tLD+lHukf4bc/VGRsyf9LU8Ka7okYs2c9j2 hCbBiCXH9YU6dk0x93oNopfWVenuaNqvyxbG4chsYNGeqLFBfnskg01U/UPrBnDgGAdi SgS8swNpDMKTCk0L9wZmvp39E7j7I6+lAFVD0XQE6ehvWMh4y/hS/1u/dGqvaoFIdjIJ PaJF8VAZHJH4jrqkrkRX4LM7MmIpCYok2MUJV5AEzpqr8JIQgbMg6YTiB3/3zYoZ9Rkf ToEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=ylxB+Hx++LEIgDce19t2otGtYWyC/YHt80P7LQP09MU=; b=GNhWiKYVYtpnBg7y0Xpl6//nDjCPBiMjmC3JvzDsuepFZct/4/1kRZ+53mxdB7q4kg qxfDuH4evGAVG+1qjk1vNG+Mlu1Iw2ty+uG9V9FarpKSrPdZhun8EZasj57VyLYUYavi IyMZai36B0Q6EceMfMMyJ58UKSml0ErYCCoVSRgDPZFkaVs49np7sG0Ps5Mp8r00Q+zj FgFaLsdLcnu6xBqB2AQgQQ2J2FD+pPeMzArIwqSa/Xiq9gTzSryi1hVNaEiJTBi+nPj5 nbflM08XphVk0P3yIUCpLXIKN0lZBFTBRH/n6MhkIahQsKtOHN09gMCogoN5WP+OuTp2 tnrQ== X-Gm-Message-State: AOAM532aLPNgmWBqWtX09uOKiUcmtdQU8HMZf7X+UQ5q5liAI3X3lpMz Tu8zH6Z/+jGwmlbmnoet9cs= X-Google-Smtp-Source: ABdhPJxs1z1Cj8A1dElHpP1eXJVgfrm1cl4dkEe0g7tWz1hxqfq4b2gQ/DG8+jgzKwQTof8D/nex1w== X-Received: by 2002:a17:902:9b95:b0:151:533b:9197 with SMTP id y21-20020a1709029b9500b00151533b9197mr24919678plp.66.1650531448442; Thu, 21 Apr 2022 01:57:28 -0700 (PDT) Received: from localhost (193-116-116-20.tpgi.com.au. [193.116.116.20]) by smtp.gmail.com with ESMTPSA id u20-20020a056a00159400b0050a946e0548sm9544041pfk.165.2022.04.21.01.57.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 01:57:27 -0700 (PDT) Date: Thu, 21 Apr 2022 18:57:22 +1000 From: Nicholas Piggin Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP To: Linus Torvalds Cc: "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" , Mike Rapoport , "song@kernel.org" , Song Liu 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: MIME-Version: 1.0 Message-Id: <1650530694.evuxjgtju7.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 423A840022 X-Stat-Signature: 1fbyr3radoouyxwe91xgzpqxgr346iow Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=TI7S5wZt; spf=pass (imf07.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=npiggin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-HE-Tag: 1650531449-368752 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: Excerpts from Linus Torvalds's message of April 21, 2022 3:48 pm: > On Wed, Apr 20, 2022 at 8:25 PM Nicholas Piggin wrote= : >> >> Why not just revert fac54e2bfb5b ? >=20 > That would be stupid, with no sane way forward. >=20 > The fact is, HUGE_VMALLOC was badly misdesigned, and enabling it on > x86 only ended up showing the problems. >=20 > It wasn't fac54e2bfb5b that was the fundamental issue. It was the > whole "oh, we should never have done it that way to begin with". >=20 > The whole initial notion that HAVE_ARCH_HUGE_VMALLOC means that there > must be no PAGE_SIZE pte assumptions was simply broken. It didn't have that requirement so much as required it to be accounted for if the arch enabled it. > There were > actual real cases that had those assumptions, and the whole "let's > just change vmalloc behavior by default and then people who don't like > it can opt out" was just fundamentally a really bad idea. >=20 > Power had that random "oh, we don't want to do this for module_alloc", > which you had a comment about "more testing" for. >=20 > And s390 had a case of hardware limitations where it didn't work for some= cases. >=20 > And then enabling it on x86 turned up more issues. Those were (AFAIKS) all in arch code though. The patch was the fundamental issue for x86 because it had bugs. I don't quite see what your objection is to power and s390's working implementations. Some parts of the arch code could not cope with hue PTEs so they used small. Switching the API around to expect non-arch code to know whether or not it can use huge mappings is much worse. How is=20 alloc_large_system_hash expected to know whether it may use huge pages on any given half-broken arch like x86? It's the same like we have huge iomap for a long time. No driver should be expect to have to understand that. > So yes, commit fac54e2bfb5b _exposed_ things to a much larger > audience. But all it just made clear was that your original notion of > "let's change behavior and randomly disable it as things turn up" was > just broken. >=20 > Including "small" details like the fact that apparently > VM_FLUSH_RESET_PERMS didn't work correctly any more for this, which > caused issues for bpf, and that [PATCH 4/4]. Which is another arch detail. > And yes, there was a > half-arsed comment ("may require extra work") to that effect in the > powerpc __module_alloc() function, but it had been left to others to > notice separately. It had a comment in arch/Kconfig about it. Combing through the details of every arch is left to others who choose to opt-in though. > So no. We're not going back to that completely broken model. The > lagepage thing needs to be opt-in, and needs a lot more care. I don't think it should be opt-in at the caller level (at least not outside arch/). As I said earlier maybe we end up finding fragmentation to be a problem that can't be solved with simple heuristics tweaking so we could think about adding something to give size/speed hint tradeoff, but as for "can this caller use huge vmap backed memory", it should not be something drivers or core code has to think about. Thanks, Nick