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 94982C433F5 for ; Mon, 21 Mar 2022 23:51:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDD2F6B0072; Mon, 21 Mar 2022 19:51:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D64F06B0073; Mon, 21 Mar 2022 19:51:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C06706B0074; Mon, 21 Mar 2022 19:51:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id B012D6B0072 for ; Mon, 21 Mar 2022 19:51:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 702CCA309E for ; Mon, 21 Mar 2022 23:51:51 +0000 (UTC) X-FDA: 79270043622.26.688C56D Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf18.hostedemail.com (Postfix) with ESMTP id 0B5AF1C0028 for ; Mon, 21 Mar 2022 23:51:50 +0000 (UTC) Received: by mail-ua1-f43.google.com with SMTP id m42so6418190uae.0 for ; Mon, 21 Mar 2022 16:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UTkGkxH5z61CFvvV+2N0qMPgD0+CXKYTvEk2R706LAM=; b=LmC5XeHMDSyMfs8sqcXs4MtdfXUq+ej1d0yqeFGBoARUAOlwT6Oo6hiE8GJLAyipV7 6Ys+1yodh0I0YOEIlJio68bp2A6satdIrW9COEKhv6wvoP88UuxUhOhDwCAezrDuQDDI gJkCci+X+SERoIspL0e1CK1WwYxrGhhIA7Vi270rwI8K/6w00v/xEw9n/puGwnlQ2+Nx P6RIdkbmFMhV++N6pfqesnBvJHLkTZw5Wmgh2Cu2oZiKjAdBgtSd6+dgSnBhyLDADBHq rbKMhEKI3pdjITumRYZ5K9ZeL1SiavuOytAg4+BsM/JrK7qfhzCpXZAg7b7ec0EWFjKa GP0w== 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=UTkGkxH5z61CFvvV+2N0qMPgD0+CXKYTvEk2R706LAM=; b=LkOK8Bpznfv/6BGdeoke9QjbgrZ5R2PdNUV+BUNjo99VYYKnpFbNA+1bchIIfwpsiO ahvWNIcVWFC9dVHOaOLIsYwgjYX1uFcByrflei4piQSl+97TsutYvQXIGVWf2H5B59/9 VDpVxCFiTrwSDxnPY1J5NXVLW1353fVtcHynu/6BNm1lA4bSANs30K56KiXo10ru9of9 /CWS6KnhpP6HrGgz87f+OpEbh/9/B8AFoZrUm2CvveDwwAF5WDuMk2feTtgsYjAOOfcy U+qQoPUpnY/W5iFJEPRruPve4b3kuXy+ECWILoE9KMxybCvQqPJwuDnyM9DiHkWQoN82 ww1Q== X-Gm-Message-State: AOAM5333CAqs3QbAH0vcu0tNyffRTTVJntFVwYUp5jgrb47tvlAWUY0F s5KEos99GFCbI9smcgfamA4BSzYCjAo3MefbpSzvFA== X-Google-Smtp-Source: ABdhPJxbhMJeBQEf3j1JZxDTy/ndgvixACjKlQy40+dklccM507ablsvs0srEgLOR5fHAAQwED3gOjGvVZyRkFztdhI= X-Received: by 2002:ab0:6499:0:b0:351:b9b5:9715 with SMTP id p25-20020ab06499000000b00351b9b59715mr6585658uam.17.1647906710154; Mon, 21 Mar 2022 16:51:50 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-7-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Mon, 21 Mar 2022 17:51:39 -0600 Message-ID: Subject: Re: [PATCH v9 06/14] mm: multi-gen LRU: minimal implementation To: Barry Song <21cnbao@gmail.com> 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-Stat-Signature: yghoydsh85cjoh4t57oo1pnyaoeixrgo Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=LmC5XeHM; spf=pass (imf18.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0B5AF1C0028 X-HE-Tag: 1647906710-72797 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 Sat, Mar 19, 2022 at 4:14 AM Barry Song <21cnbao@gmail.com> wrote: > > > +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][zon= e] - > > + 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? Yes. > isn't it a bug if(lrugen->nr_pages[next][type][zone] > 0)? shouldn't it b= e=EF=BC=9F > > delta =3D lrugen->nr_pages[prev][type][zone]=EF=BC=9B No. The gen counter in page flags can be updated locklessly (lru_lock). Later a batched update of nr_pages[] will account for the change made. If the gen counter is updated to a stale max_seq, and this stale max_seq is less than min_seq, then this page will be in a generation yet to be born. Extremely unlikely, but still possible. This is not a bug because pages might be misplaced but they won't be lost. IOW, nr_pages[] is always balanced across all *possible* generations. For the same reason, reset_batch_size() and drain_evictable() use for_each_gen_type_zone() to go through all possible generations rather than only those between[max_seq, min_seq]. I'll add a comment here. Sounds good?