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 D3F25ECAAD1 for ; Thu, 1 Sep 2022 17:42:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75D9280034; Thu, 1 Sep 2022 13:42:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70C7D8000D; Thu, 1 Sep 2022 13:42:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AD9E80034; Thu, 1 Sep 2022 13:42:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 48ACD8000D for ; Thu, 1 Sep 2022 13:42:06 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 256DE1C6246 for ; Thu, 1 Sep 2022 17:42:06 +0000 (UTC) X-FDA: 79864235052.11.1EECD39 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 94832A005B for ; Thu, 1 Sep 2022 17:42:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662054123; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FJJ0qYVRnAgLcuZMSjxbZMetNdfRSF7eNDaKLQRRUXM=; b=AWFi4WHKMPIjqf+vwK9cDppYGDv1oyGX9qoRwKZ69N45NhhngaYwsn5Pl1onBR2cpwRMJ3 DBYttZ+4Cp6Kcson5Fn0UQepD86kVE2houYiqr1TG+61W7NTXjFEZSaazyQR7HTWyCnb5W YIUbleLf9vFhkLNKqBJkrxeDtKgL8hk= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-145-IMY-5xTyPl-FVzHKOy3v5A-1; Thu, 01 Sep 2022 13:42:02 -0400 X-MC-Unique: IMY-5xTyPl-FVzHKOy3v5A-1 Received: by mail-qv1-f71.google.com with SMTP id db3-20020a056214170300b00496c0aabfc9so11715894qvb.16 for ; Thu, 01 Sep 2022 10:42:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=FJJ0qYVRnAgLcuZMSjxbZMetNdfRSF7eNDaKLQRRUXM=; b=EMahJ/O1fycgK8fm+tC1uoNJYS8hkhPWRUbKEdXFKwswUBUXy8tLhvG7MVSWTGoth7 3H0Tp4zclX73t28vxpHWnnUawOrD535YAX5K3P1NYHkw6eIvAKjD0GhWYfQyetUllVp4 aV1+18wR90bc7aSRtUpO1mgMIh/6qDKOGuJOAMMfMN/dC8HiVhLHlAOvNI+FCzW1/MYE zpqu4EyD3ZvOvxosXeUQMvP1LSdazpESkyHcCqjg2ejl6ayHexbZTmQT4HVG3CaHEQvC z3CKcHXBZd8YPUOdg3V20t9I1BXF9ii7aWc5Ye8fdrOUj4FqheRBtXwDBDxJ3sWnu2/A KU/Q== X-Gm-Message-State: ACgBeo2+zEEki8nfInpHR2zWsyFfy/Z9FOljeGqiyQiWFOUhxWBYj3dF Zv1d3reDThyhGn+qohnRjRDimpK2m+b5zkMOw0Nw5XxTovDNLEyFAAAfFy0hZK2BWJjwM1fTVEs n9rxjaKJeslQ= X-Received: by 2002:ae9:e64a:0:b0:6ba:e284:2102 with SMTP id x10-20020ae9e64a000000b006bae2842102mr21448785qkl.739.1662054122492; Thu, 01 Sep 2022 10:42:02 -0700 (PDT) X-Google-Smtp-Source: AA6agR7/AqLBwvxgQGrjag8RZdp9bkMzn6qTQ+vkvLkjwrJcY9zLuSyHBMu7nrPruXvlxE+Ugo1WQw== X-Received: by 2002:ae9:e64a:0:b0:6ba:e284:2102 with SMTP id x10-20020ae9e64a000000b006bae2842102mr21448756qkl.739.1662054122209; Thu, 01 Sep 2022 10:42:02 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-35-70-27-3-10.dsl.bell.ca. [70.27.3.10]) by smtp.gmail.com with ESMTPSA id hj12-20020a05622a620c00b0031ea864d3b2sm10393509qtb.30.2022.09.01.10.42.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Sep 2022 10:42:01 -0700 (PDT) Date: Thu, 1 Sep 2022 13:41:59 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Kirill A . Shutemov" , Sasha Levin , "Aneesh Kumar K . V" , Vlastimil Babka , Jerome Marchand , Andrea Arcangeli , Hugh Dickins , Jason Gunthorpe , John Hubbard , Yang Shi Subject: Re: [PATCH v1] mm/gup: adjust stale comment for RCU GUP-fast Message-ID: References: <20220901072119.37588-1-david@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662054125; a=rsa-sha256; cv=none; b=WVpdVdqFST2wY9JRPjHw/Kl/QVzLWpn6Ek6KUNcVVAqtQw3cFiQ4j/0wLmonrOad6meQ5H gZu9wA/lvRnmwAArhggUYSsiNd2cyek65Gw2Gyrq+K2Yy9bwpno1oWZJm6T8+UkxlYOBM4 twaZqiX7mmoOKyk47RcYAtvAeTnLuzM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AWFi4WHK; spf=pass (imf25.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662054125; 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=FJJ0qYVRnAgLcuZMSjxbZMetNdfRSF7eNDaKLQRRUXM=; b=Eo2N3/9F+b6asm9fRzNbE3+r0jEvb6DlaWIiVE2Fam6Sv/PcMLNpjONkrhWUwEmMxrKezT d4PmUG2kJYJUeKwss5s9JOBpzIiM53tuJBrKn+2df8mKm5bIHIwyK6aGOO6qArCbVOxRBE IeaGBNEIBnSh7KTyrSpCLN7Il252IaQ= X-Rspam-User: X-Stat-Signature: jge8tkqnyjfux855959pkbkdjrbxmdw5 X-Rspamd-Queue-Id: 94832A005B X-Rspamd-Server: rspam06 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AWFi4WHK; spf=pass (imf25.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1662054124-552008 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 Thu, Sep 01, 2022 at 06:46:13PM +0200, David Hildenbrand wrote: > On 01.09.22 18:40, Peter Xu wrote: > > On Thu, Sep 01, 2022 at 06:34:41PM +0200, David Hildenbrand wrote: > >> On 01.09.22 18:28, Peter Xu wrote: > >>> On Thu, Sep 01, 2022 at 09:21:19AM +0200, David Hildenbrand wrote: > >>>> commit 4b471e8898c3 ("mm, thp: remove infrastructure for handling splitting > >>>> PMDs") didn't remove all details about the THP split requirements for > >>>> RCU GUP-fast. > >>>> > >>>> IPI broeadcasts on THP split are no longer required. > >>>> > >>>> Cc: Kirill A. Shutemov > >>>> Cc: Sasha Levin > >>>> Cc: Aneesh Kumar K.V > >>>> Cc: Vlastimil Babka > >>>> Cc: Jerome Marchand > >>>> Cc: Andrea Arcangeli > >>>> Cc: Hugh Dickins > >>>> Cc: Jason Gunthorpe > >>>> Cc: John Hubbard > >>>> Cc: Peter Xu > >>>> Cc: Yang Shi > >>>> Signed-off-by: David Hildenbrand > >>>> --- > >>>> mm/gup.c | 5 ++--- > >>>> 1 file changed, 2 insertions(+), 3 deletions(-) > >>>> > >>>> diff --git a/mm/gup.c b/mm/gup.c > >>>> index 5abdaf487460..cfe71f422787 100644 > >>>> --- a/mm/gup.c > >>>> +++ b/mm/gup.c > >>>> @@ -2309,9 +2309,8 @@ EXPORT_SYMBOL(get_user_pages_unlocked); > >>>> * > >>>> * Another way to achieve this is to batch up page table containing pages > >>>> * belonging to more than one mm_user, then rcu_sched a callback to free those > >>>> - * pages. Disabling interrupts will allow the fast_gup walker to both block > >>>> - * the rcu_sched callback, and an IPI that we broadcast for splitting THPs > >>>> - * (which is a relatively rare event). The code below adopts this strategy. > >>>> + * pages. Disabling interrupts will allow the fast_gup walker to block the > >>>> + * rcu_sched callback. > >>> > >>> This is the comment for fast-gup in general but not only for thp split. > >> > >> "an IPI that we broadcast for splitting THP" is about splitting THP. > > > > Ah OK. Shall we still keep some "IPI broadcast" information here if we're > > modifying it? Otherwise it gives a feeling that none needs the IPIs. > > I guess that's the end goal -- and we forgot about the PMD collapse case. > > Are we aware of any other case that needs an IPI? I'd rather avoid > documenting something that's no longer true. I'm not aware of any. > > > > > It can be dropped later if you want to rework the thp collapse side and > > finally remove IPI dependency on fast-gup, but so far it seems to me it's > > still needed. Or just drop this patch until that rework happens? > > The doc as is is obviously stale, why drop this patch? > > We should see a fix for the THP collapse issue very soon I guess. Most > probably this patch will go upstream after that fix. No objection to have this patch alone as the removal statement is only about "thp split". But IMHO this patch alone didn't really help a great lot, especially if you plan to have more to come that is very relevant to this, so it'll be clearer to put them together. Your call. > > > > >> > >>> > >>> I can understand that we don't need IPI for thp split, but isn't the IPIs > >>> still needed for thp collapse (aka pmdp_collapse_flush)? > >> > >> That was, unfortunately, never documented -- and as discussed in the > >> other thread, arm64 doesn't do that IPI before collapse and might need > >> fixing. We'll most probably end up getting rid of that > >> (undocumented/forgotten) IPI requirement and fix it in GUP-fast by > >> re-rechecking if the PMD changed. > > > > Yeah from an initial thought that looks valid to me. It'll also allow > > pmdp_collapse_flush() to be dropped too, am I right? > > I think the magic about pmdp_collapse_flush() is not only the IPIs, but > that we don't perform an ordinary PMD flush but we logically flush "all > PTEs in that range". Yes there's a difference, good to learn that, thanks. -- Peter Xu