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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A30DC433E0 for ; Thu, 6 Aug 2020 14:42:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6CAC523105 for ; Thu, 6 Aug 2020 14:42:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TTazq0sC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CAC523105 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9018B6B0002; Thu, 6 Aug 2020 10:42:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B21A6B0003; Thu, 6 Aug 2020 10:42:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C85E6B0006; Thu, 6 Aug 2020 10:42:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 67C1D6B0002 for ; Thu, 6 Aug 2020 10:42:00 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E117C1F06 for ; Thu, 6 Aug 2020 14:41:59 +0000 (UTC) X-FDA: 77120408358.30.road77_0a17cb926fb8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 9A98B180B3C95 for ; Thu, 6 Aug 2020 14:41:59 +0000 (UTC) X-HE-Tag: road77_0a17cb926fb8 X-Filterd-Recvd-Size: 5530 Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Aug 2020 14:41:59 +0000 (UTC) Received: by mail-il1-f194.google.com with SMTP id z3so30411187ilh.3 for ; Thu, 06 Aug 2020 07:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e+hO/GQg5P+bxQrVbS65C7Iq18WrIeXspRsLAKl6TmY=; b=TTazq0sCZRjto6OkfUWBKf1/2X3NxXYV0alJTRb9iha5CV4YG5RQoIkNcndd1jABiR 6arDxJ3PjTvaYsRp6BllbjuvMHvBuTNR+lg4jQNgZ5AVcQMLBVKGZ4UAUBzSxWzbVYg2 tTCnPg13nUaa3FAtnSUfhTAaz6PZe1omA4g5kN0i1eII5KKVMcO8E3f9lC8xg0C0jB5J Zyv4OffZSOkiwZ0V+e4ueUrTF9n2C5jfgfZ8t5TfeDmduvFro3ac3U6b0PBCIfSbloiq vgfcxRw9yG6TqBpCInEUWFfmcDx/FTzkyt4QDblpYEgmTXYWO4goZnIgoPEGA2Kxd943 fRxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=e+hO/GQg5P+bxQrVbS65C7Iq18WrIeXspRsLAKl6TmY=; b=AfDETZeyhhQQ0iKHUA8GQSwVNiaCSiP+kwSDDsv/rDz4GqViMbpvaTC94mMrp8Yv++ O1UUgF4qv0cfhqBYiIKlbbmoeNMI2J+jBM1rLUWcrlHpHLUHhSAbmYL70jwsv7EQ/Iqk K58HlDFFyF97vr9TexJxN1WR3XtOj6hGQzmQSU1PCNCbsgMOwxwJMB85Btv4LBN9uvl4 xSZBrmD1E+Ogl4Qxf3t61F3evr2F2UbEN3n6tQD52yBiRMvkp7cK+3OyrgCb56wAj6B4 jHu0ylTUlnQ2FpYWIRMan8hVoZRBb9KaB9rSCfsYR49binPBG3/3MN1Tzs6I4cpWxZs/ gClw== X-Gm-Message-State: AOAM5314fuqeTj7KaFbJOzhFGr1jtPuNeldVutajhLL+4KVlligTcYpX cwZLVVH2aPY/1aqgETwdMyrei/wjJNs5FP4X+/0= X-Google-Smtp-Source: ABdhPJyMYILla6HQYNcIPeMni5KOhLnUAjTEmattKCsp0+w1QGXrfuR6V4jG4VzEak6WOHcFfOeQS6f4Hb4mhukcP+E= X-Received: by 2002:a92:5b12:: with SMTP id p18mr3323594ilb.95.1596724918389; Thu, 06 Aug 2020 07:41:58 -0700 (PDT) MIME-Version: 1.0 References: <1595681998-19193-1-git-send-email-alex.shi@linux.alibaba.com> <1595681998-19193-14-git-send-email-alex.shi@linux.alibaba.com> <9b906469-38fb-8a4e-9a47-d617c7669579@linux.alibaba.com> In-Reply-To: From: Alexander Duyck Date: Thu, 6 Aug 2020 07:41:47 -0700 Message-ID: Subject: Re: [PATCH v17 13/21] mm/lru: introduce TestClearPageLRU To: Alex Shi Cc: Andrew Morton , Mel Gorman , Tejun Heo , Hugh Dickins , Konstantin Khlebnikov , Daniel Jordan , Yang Shi , Matthew Wilcox , Johannes Weiner , kbuild test robot , linux-mm , LKML , cgroups@vger.kernel.org, Shakeel Butt , Joonsoo Kim , Wei Yang , "Kirill A. Shutemov" , Rong Chen , Michal Hocko , Vladimir Davydov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9A98B180B3C95 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Wed, Aug 5, 2020 at 6:54 PM Alex Shi wrote: > > > > =E5=9C=A8 2020/8/6 =E4=B8=8A=E5=8D=886:43, Alexander Duyck =E5=86=99=E9= =81=93: > >> @@ -878,9 +877,8 @@ void release_pages(struct page **pages, int nr) > >> spin_lock_irqsave(&locked_pgdat->lru_l= ock, flags); > >> } > >> > >> - lruvec =3D mem_cgroup_page_lruvec(page, locked= _pgdat); > >> - VM_BUG_ON_PAGE(!PageLRU(page), page); > >> __ClearPageLRU(page); > >> + lruvec =3D mem_cgroup_page_lruvec(page, locked= _pgdat); > >> del_page_from_lru_list(page, lruvec, page_off_= lru(page)); > >> } > >> > > The more I look at this piece it seems like this change wasn't really > > necessary. If anything it seems like it could catch potential bugs as > > it was testing for the PageLRU flag before and then clearing it > > manually anyway. In addition it doesn't reduce the critical path by > > any significant amount so I am not sure these changes are providing > > any benefit. > > Don't know hat kind of bug do you mean here, since the page is no one usi= ng, means > no one could ClearPageLRU in other place, so if you like to keep the VM_= BUG_ON_PAGE, > that should be ok. You kind of answered your own question. Basically the bug it would catch is if another thread were to clear the flag without getting a reference to the page first. My preference would be to leave this code as is for now. There isn't much value in either moving the lruvec or removing the VM_BUG_ON_PAGE call since the critical path size would barely be effected as it is only one or two operations anyway. What it comes down to is that the less unnecessary changes we make the better.