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 271D8C54798 for ; Wed, 6 Mar 2024 03:05:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 983A16B0082; Tue, 5 Mar 2024 22:05:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9332D6B0085; Tue, 5 Mar 2024 22:05:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FB8A6B0088; Tue, 5 Mar 2024 22:05:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6CD506B0082 for ; Tue, 5 Mar 2024 22:05:45 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 312FF40B97 for ; Wed, 6 Mar 2024 03:05:45 +0000 (UTC) X-FDA: 81865124250.30.81AC90D Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf26.hostedemail.com (Postfix) with ESMTP id 6B5B1140003 for ; Wed, 6 Mar 2024 03:05:43 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=blkxrqGZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709694343; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=x+hsqw7WOzdzCHcjTyygd6FMnULBscM6RpZyMhIJC5s=; b=1a2Tytz41+ha34nVulGtVL7eeKt0axHUGhJqGZP4dSAOH64rAolcmA8U+a42tGXaQU5xHJ v2IRpjvHeBBRqR9OhA8TAjuL6dg38b11pz+TF1WZWH0fCia+BZFp2TkhW8Mrgnlf4deNJB Ah4sU4fIWObZ+YGGRP0cT/4lPm3psBI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=blkxrqGZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709694343; a=rsa-sha256; cv=none; b=IdLmjJbeffylnhZGYQ+wyxRoZ7q64z3uuwEkT55yQeytIE/zHlwBfN1xcqgDrBjfGqq5av FpF3leOQCQMbfCOyVPNvTA3CGXi4TcmmY/Lr/q3JwuOrFYQU8bPTKQyYoi2Kyapf0lPqB4 Weov/3quTQtL3otgkzh0RBr8gqdkOj0= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-412c79213c8so19095e9.1 for ; Tue, 05 Mar 2024 19:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709694342; x=1710299142; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=x+hsqw7WOzdzCHcjTyygd6FMnULBscM6RpZyMhIJC5s=; b=blkxrqGZjQtBNaQbyLEa21Nv+HB+BIXJ1tKhZF2EWoxeZMj2/GVhaiITHaO1ORuN7O tySgWM8wzBR9kfsThOVED7VtWOjZ/gT73BTljU+tqQk7Ud8t/q6U2zwxQugFRDY/nHLF OHypXZOuPcY6WOcVwlbSeQ9KugHzzY8Q6B7A/921tlBk4nvbVqAM4qVXHJFw++FupNwy qXiUsm5nCZvgEoB9zvpNWWJOGlab3xx/Vx5zzsXzI1g0xWOKIvjD5AIzu5PQYzX17RmB 0K1mQ6A7HSL4eYVh9Qb1GTE70e7xpvaY1dAuVO1AXly7HEcobr8H/ZRsMloI2eaR+lkv cGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709694342; x=1710299142; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=x+hsqw7WOzdzCHcjTyygd6FMnULBscM6RpZyMhIJC5s=; b=nuLS87c2lXcjkf7NoCYt7qTvurrZDfEvCENf34upymSqKZ4p93N7ZEfJ3106p+0lCi BM2zh6tVqBho3imHsgZqVLbF5cMSHksxZThPNfNXSOLA7PnmsHEcTWszqERINyms3C0k dF6Ta/JxuuaaZFM9C0Wq5zP2KPgHaU/DKWo/Nj3Vy5W+ylQ5dGwfjJdnByHU/m593Umy Gatq5AnjiPwmeeU+335jorZ7jNiVqnzuLkZHHdQ/gJLb98lkc2qo9IuOCcXFaeJjHysQ IDZXqONgvk4teaLIgq54d5UJxJ/L/YeM7C5fIRi//cLEW85Qf40ggyLovYkzdZh/jPs1 ISGw== X-Forwarded-Encrypted: i=1; AJvYcCUOWyyfvnwyHM0xpj90eunZi3wOTz60fp/D5u9g7Bqn+olmreNihJ/AA1TFwTusOKuPZfXxKTVL0pkbZLhuMCXlL3k= X-Gm-Message-State: AOJu0YwiTVq++Qh7VzowFWCXg9JBAfF6/7VBX6MUAm0iDxLkp9BcT+7u VGU0G648PMXqyy9DS1LudVCyhVFWuVjSwFORg/2UlN9J/qQojZJX0LzHfqZcw8D8i9Et+LjJtkO rptWWUtUFYxhwN2NI1kKUvlQCirAs1gi+g3nU X-Google-Smtp-Source: AGHT+IEwbH1zAUe2q/0pGf9fRGqr9nXAkuumH82UM9VD0sON5b0PsNvbakqH2eZDbSgCuWfG/9eckcMQ+aJgg3Gcw1M= X-Received: by 2002:a05:600c:68c4:b0:412:cf3f:6a0 with SMTP id jd4-20020a05600c68c400b00412cf3f06a0mr270101wmb.3.1709694341654; Tue, 05 Mar 2024 19:05:41 -0800 (PST) MIME-Version: 1.0 References: <20240229183436.4110845-2-yuzhao@google.com> <20240305084116.25103-1-21cnbao@gmail.com> In-Reply-To: From: Yu Zhao Date: Tue, 5 Mar 2024 22:05:03 -0500 Message-ID: Subject: Re: [Chapter One] THP zones: the use cases of policy zones To: Barry Song <21cnbao@gmail.com> Cc: Vlastimil Babka , corbet@lwn.net, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6B5B1140003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: p7bhjr3wr6g4jp5ur1qjtujs9zboxi84 X-HE-Tag: 1709694343-211004 X-HE-Meta: U2FsdGVkX18ltb7eUYqtPCw/XAi08uPAFSOTWaVFO2z0rfvgZCbzRcXqg3+mX57YX57ib76xhyDGsjE+gqh2cq/n7vN7f6aAMMC8uxJUiHoq5aptxsULcH95kinip3uhqHv00Oyo8E9Zwtaxmwncl4NmehUx04gKQk0NfEYzJEtkfdt1JLblVf7c04nBNnHSmzr2GE+j+dQqBV9/nM+Va8Q24Tpt0gOg94dVoT83M+bjeufOMse3kEGuLyG+jDyg+T5UP2Yy3GvUpUTlpj919KRa8Y+ZRfX6HMNVgFBvBCUv2LJFCcr5hnorS1hfH4w/mRpqT3B2ptI+oF9CM6PbjRExcb3ZcPQwHmNAFAML0f7z+68s7o/jJpRW5WXxK+Z5K6qz24152uljFGJiSI/NDXAikGS7l1NS5Qqy283PI6z/bBre1FunE1fphUJZeZMVn3DwuwfsDxSBk24P9nB5yYpagYY7KY/TMBpqnzzaBB0mZgbsIxCa8VuZdnPlWfLQBE+GpY5ZDzUs0TodkWTK5XjoNE2mhtfWU4m8I0/uK4jhbqlaYDgnzig2FELBT1ss5nNPHW4i3Wox7plk93B3MHdHBLSlHa6ghAIZIMSqO+D2TxikD/RDV4WLtXLQtJKfzrdOD2dp63qfaR0PnJi6wl/ipKtgEcRddIxCh6T1MFGby0ggHrOKWnRCPCw+QKK3EgYeaCKNcaaLGH8PWUScd1t8F2pcFkKnW+Im/Wz5hXD1n/IkujipgZ3P17toI9+I50W794/tzovBGuKIR9VXXc5jDWfI/T8p21WheIxEIYudgnv8Ze8qXpfjecKCv6O9Ba+PhaSXjLWTsemEKc8WFucVTOcqOYX0EianA7F8ajzJaFRHtwgY09UDDfq/G/xKC8Y4f2+pfoPND7fqG8J7IQFFZ08MByWTqJF+bwV1k8pHnBYmZVdYhjnCHzhXCFvsoAzGegs0ewt/sdTMzf9 bdA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000522, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 5, 2024 at 4:04=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrote= : > > On Tue, Mar 5, 2024 at 11:07=E2=80=AFPM Vlastimil Babka = wrote: > > > > On 3/5/24 09:41, Barry Song wrote: > > > We did implement similar idea in the pageblock granularity on OPPO's > > > phones by extending two special migratetypes[1]: > > > > > > * QUAD_TO_TRIP - this is mainly for 4-order mTHP allocation which can= use > > > ARM64's CONT-PTE; but can rarely be splitted into 3 order to dull the= pain > > > of 3-order allocation if and only if 3-order allocation has failed in= both > > > normal buddy and the below TRIP_TO_QUAD. > > > > > > * TRIP_TO_QUAD - this is mainly for 4-order mTHP allocation which can= use > > > ARM64's CONT-PTE; but can sometimes be splitted into 3 order to dull = the > > > pain of 3-order allocation if and only if 3-order allocation has fail= ed in > > > normal buddy. > > > > > > neither of above will be merged into 5 order or above; neither of abo= ve > > > will be splitted into 2 order or lower. > > > > > > in compaction, we will skip both of above. I am seeing one disadvanta= ge > > > of this approach is that I have to add a separate LRU list in each > > > zone to place those mTHP folios. if mTHP and small folios are put > > > in the same LRU list, the reclamation efficiency is extremely bad. > > > > > > A separate zone, on the other hand, can avoid a separate LRU list > > > for mTHP as the new zone has its own LRU list. > > > > But we switched from per-zone to per-node LRU lists years ago? > > Is that actually a complication for the policy zones? Or does this work > > silently assume multigen lru which (IIRC) works differently? > > the latter. based on the below code, i believe mglru is different > with active/inactive, > > void lru_gen_init_lruvec(struct lruvec *lruvec) > { > int i; > int gen, type, zone; > struct lru_gen_folio *lrugen =3D &lruvec->lrugen; > > lrugen->max_seq =3D MIN_NR_GENS + 1; > lrugen->enabled =3D lru_gen_enabled(); > > for (i =3D 0; i <=3D MIN_NR_GENS + 1; i++) > lrugen->timestamps[i] =3D jiffies; > > for_each_gen_type_zone(gen, type, zone) > INIT_LIST_HEAD(&lrugen->folios[gen][type][zone]); > > lruvec->mm_state.seq =3D MIN_NR_GENS; > } > > A fundamental difference is that mglru has a different aging and > eviction mechanism, > This can synchronize the LRUs of each zone to move forward at the same > pace while > the active/inactive might be unable to compare the ages of folios across = zones. That's correct. The active/inactive should also work with the extra zones, just like it does for ZONE_MOVABLE. But it's not as optimized as MGLRU, e.g., targeting eligible zones without search the entire LRU list containing folios from all zones.