Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1021961rwe; Thu, 1 Sep 2022 11:08:21 -0700 (PDT) X-Google-Smtp-Source: AA6agR44qoZvuCMgGFf8w8WU5NMwi7XbYW5bpbw62O23pCe3Vsaiz7lwXHFYoMoWWYMzYjUBbNFh X-Received: by 2002:a05:6402:28cb:b0:43b:c6d7:ef92 with SMTP id ef11-20020a05640228cb00b0043bc6d7ef92mr30045416edb.333.1662055700870; Thu, 01 Sep 2022 11:08:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662055700; cv=none; d=google.com; s=arc-20160816; b=CQpd2fQDt+ighrvCl1G0gQ4/xTbZxPbhU20X5+PYRYJ/JIfeTHx20yBF2PWgxTFGac rMaaLFvWPlXxZRCeFGUcx1Bxe2pvBJB7lhOATtMWcNryt8jymcy3FEtqpNnKsUMexzFW 58wSVhR9tCzeImD9Tj0gnUrwz1UmhL2W56Ky4YgUk+eiQYxIhLuNPjR3wpQt23S+4f6A Xk0NCAI+9j1kKZcFov3Hl2NRWyrupYunUHsSJpIA4g0ZnxvMwVNuvvHjFuyj5KeEQDhS yk7DoUA95FI20kr3uooRvFaTX6OQRQ8VINNOZQ0dxCFyTGeTdVUQtoWpIqj2vcytp8Z4 l0lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ydOUsvfoYP5w3ZdcSNr57xEXqz42yurihKzVQuaAqlU=; b=BGnm1+Ju5W05m3AYSp0doWQF0n4Gsq1KCPlxbSgOCNQTLfVRgGuEfTtDY8kiAHy+Xy +HP3KGXIjIBlMc+AwsOQOPr0LCPaW8fdUwzYWcnTLiD8UBD6xhVz5RLwhsCs3y4u5VOW 0X+QgqqV4eJHeKyYGMiQYjj0Xgg2WhH5EUcTK6V++N1JhrUco7OCgXlwPuRRW6aI46XR w4jL2N3dgq8mIj6y6dc3ChYWXe5mcoUeSwwabv71Crp0EeIfTR7/J86i8P+h6VEzEHd2 RjSJwFNTaBccZHNir6XhdYWPFTbvzUxy2aek/ico7Ch2+05BB2Znm/wbZMslBqDkUsc3 ZPMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=PrWSLe97; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hv20-20020a17090760d400b007419475b220si9103211ejc.747.2022.09.01.11.07.53; Thu, 01 Sep 2022 11:08:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=PrWSLe97; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233769AbiIARvF (ORCPT + 99 others); Thu, 1 Sep 2022 13:51:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231304AbiIARvD (ORCPT ); Thu, 1 Sep 2022 13:51:03 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 541C7606B0 for ; Thu, 1 Sep 2022 10:51:01 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id p8-20020a17090ad30800b001fdfc8c7567so5958235pju.1 for ; Thu, 01 Sep 2022 10:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=ydOUsvfoYP5w3ZdcSNr57xEXqz42yurihKzVQuaAqlU=; b=PrWSLe97cVkJlciww9uG8TE8kFuxL/HQILWj2oC8RGORwaCmDjC50hmfLyGgH4UndZ NBbX37mSiYM7gajDrqE/v4Lj9T0sJUMZjRvkeMJ3SW0OHH3hkr3OpY0nbttpgovV0Ipc x2gYZQ7qTUMP+ZzI+cuhHtm8TVA1+eI3l8m/r1N7eaIWvZS8z8pGda5MnrHYVzRnldWh v0N0oeUshMQ22jXKYXWCVeOfNHvmMg6iFKg17p6uaqCOcGG2oqziX9bqWyggUFoVxkA5 Zd8IFgNrrDs65mwyXDKnVVH4TugPbVlmzjLo+xRoRv+kB1prFyQDFCLxqs1EsYB+xdBg 2OOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=ydOUsvfoYP5w3ZdcSNr57xEXqz42yurihKzVQuaAqlU=; b=S4EWs8oyHpKuilMP6P2m0yvku/RsoCqynsIfDbFi/LeaZeeNuv/ejlTbCQG8g2UdyR H5I7KzswzvSFHOQ7xupUTjh4f1JeYJaAjyLMvZ8Ryjencc2riiHU6h9yqv+1neUW7RG3 +VqL7a09DkdQQS/NxUpDyi7sKHTl72MEPl61q6OT7qmjxgcAyzq4+1OmD8w/zVx0ypn2 t0iZy9sxwjPfc2BZGRgn9hKVbAhjGsPcavHC+FdKBYQgc3yb1PEj8KLHBrHTmjXdWhlM L6kRnL/DQv0pyArNFw5bIH1Uq3K7sAXGL6cYZwu3p+MwJH7pRy0U5pjO6N3AEr9258c8 Ivkg== X-Gm-Message-State: ACgBeo35PsNLqyuoIH8a0/2ysLiE4R8XfSdbFes2icmmGUY54XbOtAJ1 5Q0473wnjuR4CQlK4R9kMKx1FcNdqeeP/v7cEVs= X-Received: by 2002:a17:90a:bc9:b0:1fb:c5bf:e9d with SMTP id x9-20020a17090a0bc900b001fbc5bf0e9dmr292313pjd.21.1662054661221; Thu, 01 Sep 2022 10:51:01 -0700 (PDT) MIME-Version: 1.0 References: <20220901072119.37588-1-david@redhat.com> In-Reply-To: From: Yang Shi Date: Thu, 1 Sep 2022 10:50:48 -0700 Message-ID: Subject: Re: [PATCH v1] mm/gup: adjust stale comment for RCU GUP-fast To: David Hildenbrand Cc: Peter Xu , 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 1, 2022 at 9:46 AM 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. > > > > > 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. I will be working on the fix. > > > > >> > >>> > >>> 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". Yeah, because THP collapse does copy the data before clearing pte. If we want to remove pmdp_collapse_flush() by just clearing pmd, we should clear *AND* flush pte before copying the data IIRC. > > Apparently, that's a difference on some architectures. > > > -- > Thanks, > > David / dhildenb >