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=-6.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BA3F3C00A89 for ; Mon, 2 Nov 2020 15:11:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E72842084C for ; Mon, 2 Nov 2020 15:11:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="fvxCbUcg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E72842084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 497B46B006C; Mon, 2 Nov 2020 10:11:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4207B6B006E; Mon, 2 Nov 2020 10:11:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C1FD6B0071; Mon, 2 Nov 2020 10:11:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id F31376B006C for ; Mon, 2 Nov 2020 10:11:55 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8C766181AC9C6 for ; Mon, 2 Nov 2020 15:11:55 +0000 (UTC) X-FDA: 77439818190.08.hands23_2e14ed6272b0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 6A1831819E76F for ; Mon, 2 Nov 2020 15:11:55 +0000 (UTC) X-HE-Tag: hands23_2e14ed6272b0 X-Filterd-Recvd-Size: 6231 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Nov 2020 15:11:54 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id m14so9343022qtc.12 for ; Mon, 02 Nov 2020 07:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UPtv4U9PJYklpaVPZSIF4wy6HpZ+y+9XSdus7akqhs8=; b=fvxCbUcg/TaoIHaH+KHaeKyaSujnKcSUTkmfqyKh/QkKJK9U7Sv6hkYTJZuE9PsDOH qf1Tnz2zslvTItDBBEGYItyQGojO3aAIR8eUaSJpcqXBn5EEyU5wQLTeRy6/NiByQvOL tc249Rsimsi+EMBEKIonliNDNG5ojtn9hnKe3eyWzN95l7neNpaTO8/2yelL57HdyFM/ ttrYwXC6tcJvxMjYh9r4+Qoj8BFXE/p+GN5LA2/SoF5V7ZReJ2GkiN1jq3m35x2uvVDc xTtw2g7qK6VknF3fnO5bwz2y19yw58hf79Y22XgqerPNif0SPlCz8eN78jXHIUeirN0M 2Ojw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UPtv4U9PJYklpaVPZSIF4wy6HpZ+y+9XSdus7akqhs8=; b=nxQRoYW5ejEE332nDWeqit04862vudj8URiE9eWO5gtPLUzCVpGQdoCI7JmtjnLI1v jZA2b+MM/VT2V9ukSXxEqpE145K1POfhhavaRZkag36+p+X18A9Zayb6J0l6ECcsenNb MB/8zT9HQFWIqoKXJHzhcmC1ZO4CUSKSQzvpwzGewvdIbzZU9+qKgFyPq9+e/SrPtpqN PxnTTZIWfFx46KuW8wcusJFui0f1QnGwTez1jk/Wke4vLqj4Sj7gQJ0QbWaw9LnT+arX hObB0qUSAb7mF9VkMoG+2lzwfePqf8UXm/jgnWnzKHcP6rObMa0yd36PEeX2eBLrUcO7 9hbg== X-Gm-Message-State: AOAM533Srk6R17tISpu17RuQeNytdMS5hbjygnHfkF/sIggbeiR56BSl RoTJOXvN374ut5iEITfnmGRsAg== X-Google-Smtp-Source: ABdhPJxGgGlrJP934R5ihqM55D4zloX84/xMg/6bsipL0oceVlXCG3ieSqhwKu6fQ7ldx9JiYp4Lng== X-Received: by 2002:aed:3943:: with SMTP id l61mr14846566qte.195.1604329913801; Mon, 02 Nov 2020 07:11:53 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:2f6e]) by smtp.gmail.com with ESMTPSA id t70sm8003983qke.119.2020.11.02.07.11.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Nov 2020 07:11:53 -0800 (PST) Date: Mon, 2 Nov 2020 10:10:08 -0500 From: Johannes Weiner To: Alex Shi Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, willy@infradead.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com, kirill@shutemov.name, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com, Michal Hocko Subject: Re: [PATCH v20 15/20] mm/lru: introduce TestClearPageLRU Message-ID: <20201102151008.GH724984@cmpxchg.org> References: <1603968305-8026-1-git-send-email-alex.shi@linux.alibaba.com> <1603968305-8026-16-git-send-email-alex.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1603968305-8026-16-git-send-email-alex.shi@linux.alibaba.com> 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, Oct 29, 2020 at 06:45:00PM +0800, Alex Shi wrote: > Currently lru_lock still guards both lru list and page's lru bit, that's > ok. but if we want to use specific lruvec lock on the page, we need to > pin down the page's lruvec/memcg during locking. Just taking lruvec > lock first may be undermined by the page's memcg charge/migration. To > fix this problem, we could clear the lru bit out of locking and use > it as pin down action to block the page isolation in memcg changing. Small nit, but the use of "could" in this sentence sounds like you're describing one possible solution that isn't being taken, when in fact you are describing the chosen locking mechanism. Replacing "could" with "will" would make things a bit clearer IMO. > So now a standard steps of page isolation is following: > 1, get_page(); #pin the page avoid to be free > 2, TestClearPageLRU(); #block other isolation like memcg change > 3, spin_lock on lru_lock; #serialize lru list access > 4, delete page from lru list; > The step 2 could be optimzed/replaced in scenarios which page is > unlikely be accessed or be moved between memcgs. This is a bit ominous. I'd either elaborate / provide an example / clarify why some sites can deal with races - or just remove that sentence altogether from this part of the changelog. > This patch start with the first part: TestClearPageLRU, which combines > PageLRU check and ClearPageLRU into a macro func TestClearPageLRU. This > function will be used as page isolation precondition to prevent other > isolations some where else. Then there are may !PageLRU page on lru > list, need to remove BUG() checking accordingly. > > There 2 rules for lru bit now: > 1, the lru bit still indicate if a page on lru list, just in some > temporary moment(isolating), the page may have no lru bit when > it's on lru list. but the page still must be on lru list when the > lru bit set. > 2, have to remove lru bit before delete it from lru list. > > As Andrew Morton mentioned this change would dirty cacheline for page > isn't on LRU. But the lost would be acceptable in Rong Chen > report: > https://lore.kernel.org/lkml/20200304090301.GB5972@shao2-debian/ > > Suggested-by: Johannes Weiner > Signed-off-by: Alex Shi > Acked-by: Hugh Dickins > Cc: Hugh Dickins > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: Andrew Morton > Cc: linux-kernel@vger.kernel.org > Cc: cgroups@vger.kernel.org > Cc: linux-mm@kvack.org Acked-by: Johannes Weiner