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 8108AC433EF for ; Sat, 19 Mar 2022 10:14:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4B6F8D0002; Sat, 19 Mar 2022 06:14:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D5688D0001; Sat, 19 Mar 2022 06:14:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84D8F8D0002; Sat, 19 Mar 2022 06:14:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 732408D0001 for ; Sat, 19 Mar 2022 06:14:57 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CF04E182895A0 for ; Sat, 19 Mar 2022 10:14:56 +0000 (UTC) X-FDA: 79260727392.22.205803A Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) by imf09.hostedemail.com (Postfix) with ESMTP id 4265714001A for ; Sat, 19 Mar 2022 10:14:56 +0000 (UTC) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-2e612af95e3so1531687b3.9 for ; Sat, 19 Mar 2022 03:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D28RjDg0IIqsedMZiUTeTKR3AfquY6OXe4oxRWEJ2lM=; b=QGQCc9TMOPGLYL8s5mQbPX8X6J7/it2KQjPcOjm3W5A1X1wJr6lt11KRnCf4khbnPl W2RcZ1hTzC0lFofJf2N+HyT4A7715ZrFGsRd56ADXzkC3mhgR7xZnjiA3S2PAZWzvBce qBmrgRjYbV9Dtz+p9VxWq9DdvNe6r9L9KXnUadtwjQVEKqLGS11ox028JAQFMOdTw565 FlvhTZoXpMFJqyUdZrzDxHYYlm1uVq3o96a4onOm9BKYZQL5CHmFBL0Jp2d3C0CS50Y0 g8bnLQyCo8c+aEC/PMDcUVDE7TBkNK+sQNi+sAsrUAIkE+DGWpvx8M1hz0wgTf8lfoof shnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D28RjDg0IIqsedMZiUTeTKR3AfquY6OXe4oxRWEJ2lM=; b=UhVR+ekHUoM6KLZIdp55oZb8IEwNsuLufhfic/VM3xwLGYlsg3T/kZNUlNvd713VJO 5vaRuVudGrJAulhnEnSu62kgtzG4qGopIkzgwAcyWKdz1Ct48qxyD6ZWxFk7jRV6aOQf QSqIRMS7xTMKPrkBQmBDMt4HOL/5rZmFJoocQ1UsuqvxTw240r3njCa3WxSYt7p+pMhP KOt9K1UC6snIvborK8zF4f+RjkqWrwyENF8rgwxarA7VD4iAE9QO2ebDhCPAW1zuKPO6 jQbxj1YzSGrIux1lc8M9v119hlWoRO5zfCLAwY1MnHLUaWdluO6qqaRD7w+fnjgbBLCC DZXw== X-Gm-Message-State: AOAM530b+N/zYFmyVg5wpAKN4vmQmE3QP9CcHdziHcHiDRHE+zY1K1xG FM2nnG1i1pcNkWQ9J3LPJfqrKS/dfLuL8ntTRGc= X-Google-Smtp-Source: ABdhPJzJrX2B/OXlsxOEw1tdhFyFNMg00bXB1Jc7YkruqljBL7SBfoUlpJXYokrcB+ueqDcCLkyF1DinAmFTH/odJx8= X-Received: by 2002:a81:944:0:b0:2e5:e5cb:a04a with SMTP id 65-20020a810944000000b002e5e5cba04amr5799603ywj.406.1647684895529; Sat, 19 Mar 2022 03:14:55 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-7-yuzhao@google.com> In-Reply-To: <20220309021230.721028-7-yuzhao@google.com> From: Barry Song <21cnbao@gmail.com> Date: Sat, 19 Mar 2022 23:14:45 +1300 Message-ID: Subject: Re: [PATCH v9 06/14] mm: multi-gen LRU: minimal implementation To: Yu Zhao Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , LAK , Linux Doc Mailing List , LKML , Linux-MM , Kernel Page Reclaim v2 , x86 , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4265714001A X-Stat-Signature: 1qc5c4sjcw6spiyaqst3o5rwi6b9xhuw Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QGQCc9TM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.128.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com X-Rspam-User: X-HE-Tag: 1647684896-724614 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: > +static void inc_max_seq(struct lruvec *lruvec, unsigned long max_seq) > +{ > + int prev, next; > + int type, zone; > + struct lru_gen_struct *lrugen =3D &lruvec->lrugen; > + > + spin_lock_irq(&lruvec->lru_lock); > + > + VM_BUG_ON(!seq_is_valid(lruvec)); > + > + if (max_seq !=3D lrugen->max_seq) > + goto unlock; > + > + inc_min_seq(lruvec); > + > + /* update the active/inactive LRU sizes for compatibility */ > + prev =3D lru_gen_from_seq(lrugen->max_seq - 1); > + next =3D lru_gen_from_seq(lrugen->max_seq + 1); > + > + for (type =3D 0; type < ANON_AND_FILE; type++) { > + for (zone =3D 0; zone < MAX_NR_ZONES; zone++) { > + enum lru_list lru =3D type * LRU_INACTIVE_FILE; > + long delta =3D lrugen->nr_pages[prev][type][zone]= - > + lrugen->nr_pages[next][type][zone]; this is confusing to me. does lrugen->nr_pages[next][type][zone] have a chance to be none-zero even before max_seq is increased? some pages can be in the next generation before the generation is born? isn't it a bug if(lrugen->nr_pages[next][type][zone] > 0)? shouldn't it be= =EF=BC=9F delta =3D lrugen->nr_pages[prev][type][zone]=EF=BC=9B > + > + if (!delta) > + continue; > + > + __update_lru_size(lruvec, lru, zone, delta); > + __update_lru_size(lruvec, lru + LRU_ACTIVE, zone,= -delta); > + } > + } > + > + for (type =3D 0; type < ANON_AND_FILE; type++) > + reset_ctrl_pos(lruvec, type, false); > + > + /* make sure preceding modifications appear */ > + smp_store_release(&lrugen->max_seq, lrugen->max_seq + 1); > +unlock: > + spin_unlock_irq(&lruvec->lru_lock); > +} Thanks Barry