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 954C1C0015E for ; Fri, 28 Jul 2023 20:23:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BD796B0071; Fri, 28 Jul 2023 16:23:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 26F7A8D0002; Fri, 28 Jul 2023 16:23:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15D5F8D0001; Fri, 28 Jul 2023 16:23:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 07E106B0071 for ; Fri, 28 Jul 2023 16:23:34 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CD6891A0369 for ; Fri, 28 Jul 2023 20:23:33 +0000 (UTC) X-FDA: 81062145906.15.D450B55 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf29.hostedemail.com (Postfix) with ESMTP id B374012002D for ; Fri, 28 Jul 2023 20:23:31 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=iNa4V4wb; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690575811; a=rsa-sha256; cv=none; b=sz04xpiOXNfKlh9bYoTEAuEeX2qYqlpgcCLZlKDf4bmHpfZN3sMxMpsyILzSX8J+cP79sX v9It78VVySx3RZWW9IoKuweknatsp9OGGhi4+LBAl7iXr2YRzX5wCeNY1q68i5+wl6PmqW CPk3n7Bgnp+5nE38D1lOEUfk78HHU5Q= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=iNa4V4wb; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690575811; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DaL8vCWD2qZnjDMvOO1mSqawEYt68vZaybEyeqD8qzc=; b=bxKJo0UKGgcTzR6eOGpVtg8y2h+ZCAuPlrJsy1RqeMi1shKBs+5/9ovsEnvS2RVRlaKpm0 j+pnxnGWpPadiNdb4XiYbyaR1bOdYuQTddAxgwSJPpicD5iQnKP+rRdbncI6x3yLz9eRu+ NOXbtKZiKYtZFByzqpM8R93qI5pvMIw= Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-99bcd6c0282so343279966b.1 for ; Fri, 28 Jul 2023 13:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1690575810; x=1691180610; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DaL8vCWD2qZnjDMvOO1mSqawEYt68vZaybEyeqD8qzc=; b=iNa4V4wbqIB8YQAIu3YWecMdqgfDDBvx7YotKRvzxFMEkV1NPN9FFaahGfVAarwaAV kRJWDO6+avyfDWom2I0N3AENnd/ucA3n3b4Lmo9UgnRCWibEYgsywdeA1ZqkQqRmTlZh XV8dRItJxUnXX6LhTgM/AywiqSgw2XGInhu/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690575810; x=1691180610; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DaL8vCWD2qZnjDMvOO1mSqawEYt68vZaybEyeqD8qzc=; b=hnRPpsqcLN4zBU12CWpy7wxmafM2keKudop8nY2M7/pAo2ViCl5lOn5UiUX0fnvoaq liMm3Hizoq3OUFXVqUN3ZN0lvbbJmkdgKMKJZuTWy5aAWJltppJDQwQsbTV/Q8T/cIV8 LbP4UlgD0Ej/1g1tbnppIZ+LrhiK5EGlab8kF0oHkkHkVtiBMDMBhf5KGgTs1JYBy3dO FzWUMLIiWrkCs+/sPyEsNl3qkPZRREse2k+5IctXsDbMuBrAtWwnieKvZ0SNxRbj10dY bb2MfK2tw2zw6uojq2BAN5OZ0vLaQ58XPK/NVwmmsUn53O5x0P8s3Qhe9e7w/AgGLveU AO/g== X-Gm-Message-State: ABy/qLalCvwUUeKgukyuyZ+jaiEWifDAqrzZqT2eFcsx2/AQPzu8OJ5q QjG4acso7Yvrl2V4Zb9vieE3BNTJJ2SHg/fJKLrndWWm X-Google-Smtp-Source: APBJJlGzFagFeo3JMWs0m+Ig/gZHbisObXzWPFeAUBOh+4dZEFJSu8xdlc/lI+axDV6GzDmvqdjJxQ== X-Received: by 2002:a17:906:7a57:b0:988:6491:98e1 with SMTP id i23-20020a1709067a5700b00988649198e1mr339196ejo.42.1690575810004; Fri, 28 Jul 2023 13:23:30 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com. [209.85.208.52]) by smtp.gmail.com with ESMTPSA id g27-20020a170906395b00b009886aaeb722sm2400396eje.137.2023.07.28.13.23.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jul 2023 13:23:29 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5222a38c0a0so3318729a12.1 for ; Fri, 28 Jul 2023 13:23:28 -0700 (PDT) X-Received: by 2002:aa7:d507:0:b0:522:3a28:feca with SMTP id y7-20020aa7d507000000b005223a28fecamr2820293edq.24.1690575808575; Fri, 28 Jul 2023 13:23:28 -0700 (PDT) MIME-Version: 1.0 References: <20230727212845.135673-1-david@redhat.com> In-Reply-To: From: Linus Torvalds Date: Fri, 28 Jul 2023 13:23:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone fallout To: Peter Xu Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Andrew Morton , liubo , Matthew Wilcox , Hugh Dickins , Jason Gunthorpe , John Hubbard Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: B374012002D X-Stat-Signature: ng8g8inz4f74zn4bk3t8r7c4e95rrip6 X-Rspam-User: X-HE-Tag: 1690575811-829783 X-HE-Meta: U2FsdGVkX1/rN2pVryiDBcOZKLTdkvObxO80RkzPdwMVmfnRaNIEELywMLTmRr6eOG4QJOjYTWOcVhW8pI5vyhehUKzFokx72hcGjN8as4elenO60J6FKR8rGG90DWJJbnB9JaVzwzSbQQsPywJTUr+vFGgAfrkTzFMOxKsrw3XgNXlYtL9rYPl5xdag/1uuh5dnmLD8UxoIXc1Mz0MRlWVGVCv2WZcKfTt5lQjbf4olWP1JDueat5a1FfKD9Db/JKszcDSGeEivSBm5Ryj8VJS5TYSCPLKmrSPdKtEy92SnwBVgLOQTrmAEJKX+IcX+j1oyNP38781n111pmdU9KUxzXQuAXBXQte1pXrqIgabU3OGgt+kgjTtV1XLDWoMS2aO1gNwA0xcT51tbTtQGnFC8i9tEef2OH2jtmsghOM8a1bspx0ZUpG48Wzfk0mbWw9Y0Kgh4Zs2K3MG/WAPO4pUjEww7G0v2iw7diEtaeQ/jAMmER8Jo+FDS4n1ZlvZmQHCXBBms2RCBOmtSmkXlmt6+MF9ol8FechbCOlwJOnbeLUh1ea/B95+734HOaG0G2FHzdb88QulsCGs2s+6wQjnNB5uRdUAz9K8SDHKO55EUoTEDePROOpgjq9P4ODUCI0q+TzQ6zRmSHGqZpOlztwpAYPqRP3uzAkWyczWUA4keahcbZYe5o7zTjwzz9DtK6DtRaigaSZn0/HSqqSQh3KajMNftWv5kvdXFvHWeqRyIFfxpjKdseXnMVh4IaZS0i++HL8inWNOxwZgtm75o6NF6gNcUF6S08hcqP4UizcoB4/zxZ93+GKczzboQgYgoUUgmHmxAfDLbjhtcSTU9xQ5PAjAIer8KJ1iosO5xReTsfQduUvYFC91mnLAFkwZeotiyS32zytrjuos7lN+UDOngpthpMJPEGAl0tGdSee3aZrmnPw9lCiOOE1ttZzOZQ0McpDTnB3lLyJPyc+W vfHl4cOX EJSKmMVc98TAU2M+sK+q+Brjg8JPvX923FFnQdhq39Av+H0mF1UoWVAvpm3AszlnAxK0t1cxPFO/E5NTRgywHfYrmyI4YTWkhJYKYBadAUTO8zQAjE2DfAEv1m883425UglD3Pjo06aWWZPbUE07nEc6lX5Jo4aQh4iOUjy27qwpZdEc9mIUJF49o7hzV6eZJH2IdNzrMA5VWszKX+OuWJ1rxyP/XK/7xR0GNmLkZukWSYZtoSCMukbl1yHU4+xdEHw+a67hZKUuBegFJDcHFOqMYz2PysGlnM3s9l5RVYK0F+n0G2AmcEMm81RPPGenOh2hHRP7++/3S0Oe2nhtfxlyjXocl2gnhOySvZdo6ExqM1TbJPiIH8RDi8+84TFcZNuf8m8UVAaWmEe2eGqpq6Y/9fde92CD5bVlSRVgwKGFGs7qd2msQy8bwA/4JEFTlQpFAHtaa6OqucGCkut7Dx0eoSqELVRdWPEF41A5kwna9Bsww0+VXOoJ7Qv3tQWg7NgjKK53ozE8rTp25CT6OT2O6PfOvnq29SPky6JrQK0iaaBLMB0syzpGLl80pHg1/kpAq 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 Fri, 28 Jul 2023 at 12:39, Peter Xu wrote: > > But then does it means that any gup-only user will have numa balancing > completely disabled? Why would we ever care about a GUP-only user? Who knows where the actual access is coming from? It might be some device that is on a different node entirely. And even if the access is local from the CPU, it (a) might have happened after we moved somewhere else (b) who cares about the extra possible NUMA overhead when we just wasted *thousands* of cycles on GUP? So NUMA balancing really doesn't seem to make sense for GUP anyway as far as I can see. Now, the other side of the same thing is that (a) NUMA faulting should be fairly rare and (b) once you do GUP, who cares anyway, so you can also argue that "once you do GUP you might as well NUMA-fault, because performance simply isn't an issue". But I really think the real argument is "once you do GUP, numa faulting is just crazy". I think what happened is - the GUP code couldn't tell NUMA and actual PROTNONE apart - so the GUP code would punch through PROTNONE even when it shouldn't - so people added FOLL_NUMA to say "I don't want you to punch through, I want the NUMA fault" - but then FOLL_FORCE ends up meaning that you actually *do* want to punch through - regardless of NUMA or not - and now the two got tied together, and we end up with nonsensical garbage like if (!(gup_flags & FOLL_FORCE)) gup_flags |= FOLL_NUMA; to say "oh, actually, to avoid punching through when we shouldn't, we should NUMA fault". so we ended up with that case where even if YOU DIDN'T CARE AT ALL, you got FOLL_NUMA just so that you wouldn't punch through. And now we're in the situation that we've confused FOLL_FORCE and FOLL_NUMA, even though they have absolutely *nothing* to do with each other, except for a random implementation detail about punching through incorrectly that isn't even relevant any more. I really think FOLL_NUMA should just go away. And that FOLL_FORCE replacement for it is just wrong. If you *don't* do something without FOLL_FORCE, you damn well shouldn't do it just because FOLL_FORCE is set. The *only* semantic meaning FOLL_FORCE should have is that it overrides the vma protections for debuggers (in a very limited manner). It should *not* affect any NUMA faulting logic in any way, shape, or form. Linus