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 271D3C433EF for ; Tue, 22 Mar 2022 05:55:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BD7F6B0072; Tue, 22 Mar 2022 01:55:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86CEA6B0073; Tue, 22 Mar 2022 01:55:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70D5D8D0001; Tue, 22 Mar 2022 01:55:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 5E9406B0072 for ; Tue, 22 Mar 2022 01:55:58 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 18E2D610FC for ; Tue, 22 Mar 2022 05:55:58 +0000 (UTC) X-FDA: 79270961196.04.8944F80 Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf19.hostedemail.com (Postfix) with ESMTP id 984FF1A0023 for ; Tue, 22 Mar 2022 05:55:57 +0000 (UTC) Received: by mail-ua1-f44.google.com with SMTP id 63so6601104uaw.10 for ; Mon, 21 Mar 2022 22:55:57 -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; bh=qVziKtonTIkNbV/B71HuGD9fXJjRE/zSA9pL7FZgyn4=; b=rWG3R5qtX3GucWwH/rM7jmJOCfVi1T2dvoGI6lKrW+Kouh7f4j1XUU0D9xwMNzNHOo dCnFw11acEpDzgxXIxKkr9JUAeKCz8hqSXKb3u0uMF7Ds2qDxH5HRCPUWjY0KheQt5ys dVCRYr3EJc33+LNjGUoQn+m6pD7G2XugAlmc+o/BOLG9KKf5ii9XOblcuHbqLUrW6C2r GkCpVUgz7ej3LX9oiCj8+FQoXwEuWTYiR+JgnaNATpY/mb+E+UWRf4BX71w153S3JWuS iQ7HJcjF4rNDbIqhlJtMxxMFzQ46p2okOvFx3s6tVJ5pGcqFH90djo0dIcO0q1QlI5zX AfVA== 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; bh=qVziKtonTIkNbV/B71HuGD9fXJjRE/zSA9pL7FZgyn4=; b=goZnDDHtZL2xLPjMqAv1P1armmIH2fTlPuf+F6qw4I0Pptpi4JErzOhYzPqxJ5ijkI 4Eh8uuusO2gAxgpvDxXwNArxHnCoQylKph4qfvMHrMCE8mW8ho96sv2o4KcXk0vM+/rQ /rf1YEFtvq3fdpFWbPMl/+9BIbT9XPjkxcPw1QirYohSfGt2qwftiRqVU4DrbbP2UQzD mfvOc0hQwXwcUr2HWM+5LN5A5wJVGSKD+3Hp0F6BX2Lpv67Yq3xcVPzBB3im642aNvsi 4wbqNvtjoGLYBE8b9Y6rmX7/ktW1W6BM70J4jiGT/v78XictjcgEp2vwF6p0M5/1+P1v erJA== X-Gm-Message-State: AOAM533d704Ho41qpSlRpIHNv1CsaN8nUR6MsuHtxm+GwxYkd+6aO0mL js0oq3einL3xHs+wYiGGyWt4nztSDqu6EBQmFje7uQ== X-Google-Smtp-Source: ABdhPJx9NAJdm7wGUG2vKQV8Iy5sHiwmlsE4VyWbB4rB7wkz+hRMGuViJsfZh1uA1fHdTyd2MGjS27NegFyZsCL0rhM= X-Received: by 2002:ab0:77d5:0:b0:352:42d7:88c2 with SMTP id y21-20020ab077d5000000b0035242d788c2mr8221502uar.1.1647928556608; Mon, 21 Mar 2022 22:55:56 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-7-yuzhao@google.com> <877d8m7e1x.fsf@linux.ibm.com> In-Reply-To: <877d8m7e1x.fsf@linux.ibm.com> From: Yu Zhao Date: Mon, 21 Mar 2022 23:55:45 -0600 Message-ID: Subject: Re: [PATCH v9 06/14] mm: multi-gen LRU: minimal implementation To: "Aneesh Kumar K.V" Cc: Andrew Morton , Linus Torvalds , Andi Kleen , 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 , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Linux-MM , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , 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" X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rWG3R5qt; spf=pass (imf19.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 984FF1A0023 X-Stat-Signature: yuoxq4za9jfy658zykuuogm5q6rby46m X-HE-Tag: 1647928557-826928 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 Mon, Mar 21, 2022 at 11:27 PM Aneesh Kumar K.V wrote: > > Yu Zhao writes: > > > +static void inc_max_seq(struct lruvec *lruvec, unsigned long max_seq) > > +{ > > + int prev, next; > > + int type, zone; > > + struct lru_gen_struct *lrugen = &lruvec->lrugen; > > + > > + spin_lock_irq(&lruvec->lru_lock); > > + > > + VM_BUG_ON(!seq_is_valid(lruvec)); > > + > > + if (max_seq != lrugen->max_seq) > > + goto unlock; > > + > > + inc_min_seq(lruvec); > > Can this min seq update result in pages considered oldest become young. > ie, if we had seq value of 0 - 3 and we need ageing, the new min seq and > max_seq value will now become 1 - 4. What happens to pages in the > generation value 0 which was oldest generation earlier and is youngest > now. If anon pages are not reclaimable, e.g., no swapfile, they won't be scanned at all. So their coldness/hotness don't matter -- they don't need to be on lrugen->lists[] at all. If there is a swapfile but it's full, then yes, the inversion will happen. This can be handled by moving pages from the oldest generation to the tail of the second oldest generation, which maintains the LRU order. In fact, both were handled in the previous versions [1] [2]. They were removed in v6 for simplicity. [1] https://lore.kernel.org/linux-mm/20211111041510.402534-5-yuzhao@google.com/ [2] https://lore.kernel.org/linux-mm/20211111041510.402534-7-yuzhao@google.com/ > > +static int evict_folios(struct lruvec *lruvec, struct scan_control *sc, int swappiness) > > +{ > > + int type; > > + int scanned; > > + int reclaimed; > > + LIST_HEAD(list); > > + struct folio *folio; > > + enum vm_event_item item; > > + struct reclaim_stat stat; > > + struct mem_cgroup *memcg = lruvec_memcg(lruvec); > > + struct pglist_data *pgdat = lruvec_pgdat(lruvec); > > + > > + spin_lock_irq(&lruvec->lru_lock); > > + > > + scanned = isolate_folios(lruvec, sc, swappiness, &type, &list); > > + > > + if (try_to_inc_min_seq(lruvec, swappiness)) > > + scanned++; > > we are doing this before we shrink the page list. Any reason to do this before? We have isolated pages from lrugen->lists[], and we might have exhausted all pages in the oldest generations, i.e., lrugen->lists[min_seq] is now empty. Incrementing min_seq after shrink_page_list() is not wrong. However, it's better we do it ASAP so that concurrent reclaimers are less likely to see a stale min_seq and come here under the false impression that they'd make some progress. (Instead, they will go to the aging path and inc_max_seq() first before coming here.)