Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2508251pxp; Mon, 21 Mar 2022 23:01:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFCDKDJqP+cOLcG4ljaLSh1LdYFAlWbT4ii6Epgqu5BVCrXOy3cgv2stCW8jTM8D6S7wUG X-Received: by 2002:a17:903:240c:b0:153:c452:f282 with SMTP id e12-20020a170903240c00b00153c452f282mr16091828plo.88.1647928868515; Mon, 21 Mar 2022 23:01:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647928868; cv=none; d=google.com; s=arc-20160816; b=k9OdnT0FUCtFxxpHaScNlkbpOHhjfb3Tyd4AYB0wHGIF6wiwjMgB/XWJHI6ge9/Qs1 tWKd9pyZf0jd7RDNBPow7iE7FA5ZfZRD2NN5wKVVADzn84HPTb2pwbZL9ziNEncC4KvU FBCDbzSPJ773DSRiZqRD6T7Ed9y73sxC6myN68ddC991RD2XmI98k4xoQPVjtSX59WoB JkdJoMDPzIEVxauRLflnfo6jbmAN+D5bIIxslhzcjSFmk36Eu/y0Y23a04BjeDbr2I8C Mbq75sdEPjlUyqax1jge7xz6mTTDl9Ohy5IoGywUtNbszQY8dPjJR1VDrsMPZk0Y0K7/ 1Djw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=TqqfIpaYW5JGR3JKgjRylpIbTY9DrPh5H2+7LKVkXyY=; b=uuBWAOlTyps86r/6CvOrD1KV9PwOix91xeyi6SCidETLueFLCz05+Pjq4EKPJE4AvV aAOzjuTF81wd34+2wz7Qe/PZ7EH3IUkptgMeRRFuNsnm9lL/XPE+Fs2MO0P2fOn/plMB 8XKS3AVhIOEV7ejEmFF18Ms0EyrJe47WW8+N9aX1bXNJaeWgk7LIh57T97XaWnTn8O7t 49223GGTue4dXszLzyAay0NTp0ujd9TZYyuF5/JsbMukQ72hDaCHXiCO2HafRMflmrBz MlfrwUXlFVerdKGLFVIb4yfjyjb0hf/b6vbhPN1cNMQHv/hnF9Z7u7QkmkwohLkpSiSe 4a3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=Yk1O5Lck; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id i19-20020a631313000000b0038288abe5f7si5307850pgl.230.2022.03.21.23.01.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 23:01:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=Yk1O5Lck; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id ABB03BC9F; Mon, 21 Mar 2022 22:28:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236692AbiCVFaG (ORCPT + 99 others); Tue, 22 Mar 2022 01:30:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236704AbiCVFaD (ORCPT ); Tue, 22 Mar 2022 01:30:03 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 344A4DAF; Mon, 21 Mar 2022 22:28:34 -0700 (PDT) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22M47KBQ018787; Tue, 22 Mar 2022 05:27:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=pp1; bh=TqqfIpaYW5JGR3JKgjRylpIbTY9DrPh5H2+7LKVkXyY=; b=Yk1O5LcktVUoQcWy1/VJG12+S6hktSZSyaUh3TGeEjFvDh5mDbe02e3L2js/pTZqCJU2 3X6lNb9uIRGdyNMKp4dcb4hcUVudCs3hNZsNGvNjqYKaXwHAlUnS6WcUWFQ+VDKNGaDO unwcxCOXFOWn45zrrg1mrz8oa19xT/TSSwwtcO1t/Q8LDnSyNhtf8ZrjcIwChmAYnecW ucdJw/jRmR69ur7lln3Sg11CjyU50DeYJ4uJ7Y44uJjs4x1FlTjG5U6yfEGyeutGb4V4 J9pNUdIRikUclNKo0neG06P+AY1gGhe1YuT1A5hiOSzdXK6xZouO7+aP+VjLcfDCg304 lA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3expy0wdpc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Mar 2022 05:27:14 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 22M5Qc3f001357; Tue, 22 Mar 2022 05:27:13 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 3expy0wdnv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Mar 2022 05:27:13 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 22M5MmWb027594; Tue, 22 Mar 2022 05:27:12 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma01dal.us.ibm.com with ESMTP id 3ew6t9xf10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Mar 2022 05:27:11 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22M5RAap5439978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Mar 2022 05:27:10 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3BE62136065; Tue, 22 Mar 2022 05:27:10 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A1E1613605D; Tue, 22 Mar 2022 05:26:53 +0000 (GMT) Received: from skywalker.linux.ibm.com (unknown [9.43.75.167]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 22 Mar 2022 05:26:53 +0000 (GMT) X-Mailer: emacs 29.0.50 (via feedmail 11-beta-1 I) From: "Aneesh Kumar K.V" To: Yu Zhao , Andrew Morton , Linus Torvalds Cc: 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-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, x86@kernel.org, Yu Zhao , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , Holger =?utf-8?Q?Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Subject: Re: [PATCH v9 06/14] mm: multi-gen LRU: minimal implementation In-Reply-To: <20220309021230.721028-7-yuzhao@google.com> References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-7-yuzhao@google.com> Date: Tue, 22 Mar 2022 10:56:50 +0530 Message-ID: <877d8m7e1x.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Ql37j01KajwgF00k2OgU6gOK2r3sWXEJ X-Proofpoint-GUID: DAQxEiwBayf4Zp-JJHxC8P33uRYSCots X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-21_10,2022-03-21_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 impostorscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 suspectscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203220028 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yu Zhao writes: + > +static void inc_min_seq(struct lruvec *lruvec) > +{ > + int type; > + struct lru_gen_struct *lrugen = &lruvec->lrugen; > + > + VM_BUG_ON(!seq_is_valid(lruvec)); > + > + for (type = 0; type < ANON_AND_FILE; type++) { > + if (get_nr_gens(lruvec, type) != MAX_NR_GENS) > + continue; > + > + reset_ctrl_pos(lruvec, type, true); > + WRITE_ONCE(lrugen->min_seq[type], lrugen->min_seq[type] + 1); > + } > +} > + > +static bool try_to_inc_min_seq(struct lruvec *lruvec, bool can_swap) > +{ > + int gen, type, zone; > + bool success = false; > + struct lru_gen_struct *lrugen = &lruvec->lrugen; > + DEFINE_MIN_SEQ(lruvec); > + > + VM_BUG_ON(!seq_is_valid(lruvec)); > + > + for (type = !can_swap; type < ANON_AND_FILE; type++) { > + while (min_seq[type] + MIN_NR_GENS <= lrugen->max_seq) { > + gen = lru_gen_from_seq(min_seq[type]); > + > + for (zone = 0; zone < MAX_NR_ZONES; zone++) { > + if (!list_empty(&lrugen->lists[gen][type][zone])) > + goto next; > + } > + > + min_seq[type]++; > + } > +next: > + ; > + } > + > + /* see the comment on lru_gen_struct */ > + if (can_swap) { > + min_seq[LRU_GEN_ANON] = min(min_seq[LRU_GEN_ANON], min_seq[LRU_GEN_FILE]); > + min_seq[LRU_GEN_FILE] = max(min_seq[LRU_GEN_ANON], lrugen->min_seq[LRU_GEN_FILE]); > + } > + > + for (type = !can_swap; type < ANON_AND_FILE; type++) { > + if (min_seq[type] == lrugen->min_seq[type]) > + continue; > + > + reset_ctrl_pos(lruvec, type, true); > + WRITE_ONCE(lrugen->min_seq[type], min_seq[type]); > + success = true; > + } > + > + return success; > +} > + > +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. > + > + /* update the active/inactive LRU sizes for compatibility */ > + prev = lru_gen_from_seq(lrugen->max_seq - 1); > + next = lru_gen_from_seq(lrugen->max_seq + 1); > + > + for (type = 0; type < ANON_AND_FILE; type++) { > + for (zone = 0; zone < MAX_NR_ZONES; zone++) { > + enum lru_list lru = type * LRU_INACTIVE_FILE; > + long delta = lrugen->nr_pages[prev][type][zone] - > + lrugen->nr_pages[next][type][zone]; > + > + if (!delta) > + continue; > + > + __update_lru_size(lruvec, lru, zone, delta); > + __update_lru_size(lruvec, lru + LRU_ACTIVE, zone, -delta); > + } > + } > + > + for (type = 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); > +} > + .... + > +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? > + > + if (get_nr_gens(lruvec, LRU_GEN_FILE) == MIN_NR_GENS) > + scanned = 0;