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 97EA4C4167B for ; Fri, 1 Dec 2023 02:05:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7E96B0486; Thu, 30 Nov 2023 21:05:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 130FE6B0488; Thu, 30 Nov 2023 21:05:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEC336B04A4; Thu, 30 Nov 2023 21:05:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DC0DB6B0486 for ; Thu, 30 Nov 2023 21:05:44 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AC33D1A01B7 for ; Fri, 1 Dec 2023 02:05:44 +0000 (UTC) X-FDA: 81516608208.30.DD6B36C Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf09.hostedemail.com (Postfix) with ESMTP id E9B7014000C for ; Fri, 1 Dec 2023 02:05:42 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AjcLjgkV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701396343; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RPAyt2cpj8YitcbF/ZXsY/VZI0FRxkT2rx6bb0Jhrv0=; b=s7cQNygV48oBQhjsHljBL9g+wfXm3qhpq1tTCNDzxR6Fqm4Zfm1UMsHLK5hyBHYtTKTd9i oEL5S5/cQoUd/0s7xgJNmBSOXO6IW9dPAbQ/ECwVYgKt5l7k2VnIrl07ypLsZR4d8qz34x pLZEDgb2wHN2PHpwegK27n8Xaycq1hA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AjcLjgkV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701396343; a=rsa-sha256; cv=none; b=zkrj51Gd5FujAAhk+vKFqWVm1OuspzKwUvBhFZVFkAEYofiXFfwx61VxiykR52KexCJxWa F3ac3piNrgKr9olCF6h4nAL06o4RktlYb6nWw3nnNxOkwSjji/7tuVf4ceDbzPDPRkUH2q 7cGo52pjrh2qn6XF/oc6mXGbOfMr+50= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a00191363c1so222182166b.0 for ; Thu, 30 Nov 2023 18:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701396341; x=1702001141; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RPAyt2cpj8YitcbF/ZXsY/VZI0FRxkT2rx6bb0Jhrv0=; b=AjcLjgkVEipwOxe6Z93mua/Y2b7LKjqK/3dr7rUedklr98fzACyn/w0/8ZFou2B4A3 HOC99PHBKzv790MtnuLVMgPh6ZE5VKrcRZtCevdOvn4lFiGv7rrL/x49KqUkl+qtCW/+ 2k6zlxojMI0c0QMIiELgi8CQRD/9uQ9kCOKWK4X6BYzuvomaCk3BcXwM0I0Rp84lTzOj o8gk4KiO9ef3SmpITieaq2uhzH3HuqBqxBsZgEn5FTKXuN09xylOt2sKOdxI+nVHM/4f e9Ud/TDMHkM5BJ0BatHkm7qma6nplKUxbImA386bUac2PgDEh/IYV41COiyWGFNUCIMi NosQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701396341; x=1702001141; h=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=RPAyt2cpj8YitcbF/ZXsY/VZI0FRxkT2rx6bb0Jhrv0=; b=oj8DjWwvGwKf8S/WWl2Mlnb76t1Kfv5FGLsvl8XpSjGrQ0mfL1cFLxSLYAzQYQWWDa YcPw9A/nhxdZSKc4DbVzPpbrVB316CoLLI59Y29IpqfnWHnkqUj/vs6KNbLVctLEJ3li Q/BDxeYdfz1oDsobmOUZyKj/sh/ksX5SNYQUpFwPniX/E1SKtNJDBv8YyEbJ8Llmc22z U3avRbtsatSFH3pGltSysAxVjVYh8sQCDIdsEtLoTtz3m8RKN6Pyzrhu73H+vbvHmDp/ FnBrI4yS+v6By2N8PNHhF43f8NAwdjqh9q/KPrAS8dqQxSRhrgkCxCSIJIVDWphdgG2J DqbA== X-Gm-Message-State: AOJu0YwEp4MZOp/BG006YcKxU63l3sD9Py7bu3IcJ4Ho9BvibkjiGJFD bOEls8FsRHpfGWIzKV9votk28k1ql8/56sB3LtpwHQ== X-Google-Smtp-Source: AGHT+IHCWvetEn5bIjknsZ5SNFidPRGBu7iJZJNJAX9WtyEXizm24lRATxkMRAfd1FM3w1m3E6lh7LQtXHeGYezWHO4= X-Received: by 2002:a17:906:108f:b0:a19:4a1d:e5d4 with SMTP id u15-20020a170906108f00b00a194a1de5d4mr275873eju.59.1701396341082; Thu, 30 Nov 2023 18:05:41 -0800 (PST) MIME-Version: 1.0 References: <20231130153658.527556-1-schatzberg.dan@gmail.com> <20231130153658.527556-2-schatzberg.dan@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 30 Nov 2023 18:05:02 -0800 Message-ID: Subject: Re: [PATCH 1/1] mm: add swapiness= arg to memory.reclaim To: Huan Yang <11133793@vivo.com> Cc: Dan Schatzberg , Johannes Weiner , Roman Gushchin , Huan Yang , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , Kefeng Wang , Peter Xu , "Vishal Moola (Oracle)" , Yue Zhao , Hugh Dickins Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E9B7014000C X-Stat-Signature: 8ne7knz3k9ot8mpu7bm5xdew3q4h84wo X-HE-Tag: 1701396342-508843 X-HE-Meta: U2FsdGVkX18dwqGcoVGwEsZForfoY6b2eZ7Gu4S3OJlTMTNzMUD/z9W5Cf1onENUJlqCjUQV+dvNT4bfqtryr/O4LznmcoCIoaBziFaj4Lp92+h4EZZSJqMoeSx7z8hjja+q9atV6OJUuosCOU2tYQNzJi84vZy07Ho4ijeQuluI86TKiOifjlzqNqvlC/mNAlDaj5WIwc1TA4n3gmMwytK9OzImTDcQO2+bIZuUklht/sjs6vftgOlxoXehyTREbqhz2xveYKoeuvOj0jYv8p5IdyAAud5lBAT21wVxLkEfGGGUS949QpaT59MKL2jjR2iQEdldfU/HTxR63OfaRvV2Dck8Gc2HtFLpHwvjccWjGSutAqnG7oFTpb3qSGxCOJsXbV4ssY0JrmZkj+p3faCAboLLki5CG4i8hSqzZ7De6h2zG9UPphL4LN64u0BER1RSl6ForvogpDu2g8KP1iu46XuJ4NExTEpAYAllbANzAOorhyWFpMfJ64ukutJUXjBnNqfAkx0Ku8M/MP7sF5TnLjYeQ27YGwQkbH72BPZJhuYv3KeMBpLWtkJL3oKN44Ebx4Rmjm70iZ+VKtQGoSruFp81/ymgWNb5xZepaJEoIaHR3qNKc0dyQGNUundB+jPuSXPOHt8m62BgxLLo/iS2j6cnCQvnH4OaoOjJTkGFCUt1yaaZcFx/M72ewTm2o6SHztYmigXkc8ZIftsXa5525c8z4U9F70/CF6BaomuFT70o8m7mI4jfV6lKGfyzmltHWLTMVtxtuVLm45rRxyEBn2ZeZdVfzQ2GskZorpwbg5E2JvpgVaOhmXTrhxQYXFl2GaqHHAmTGThzG07N2qRXTuuglRNUrJOxqoBtUDiQ2b9X2vxJn7YTh7WAKwunasYrls0v3IcU+DJT1HVDyHwyth8k5Vo9f4j8PY4svF466wc2vli8abTE1WDdDdXSmtDd/lCoGpnIMwwd9+G 2Y5W1vhH 8LLfR3jJG1QZHUL85YkcZiac4XMh8YdxsYHVbh0xaEAi0+4X8CCWkbyZD5QI9nv2nDlrr9UYkhwQQKpWiI7OnFCdgtHBQm9e1KEDoMoJ3XH1mtX4raWSTbPPlqhqeHCohIkGx4LWnZlLh+9Yftv4Ac1dIIruISsIBfDmdVBF/rZehgy1qO78rDitTuOzQJBf2x8724FeaKONSQTWVsw/XOfLbYfJr4z0vDZVULIBcFaxMiB3nA/B4EU9XK5Tyb9M0U1t6yFbqGb2Lt8iW4HYbjH0Xhs7pZxyGuh0ZRcmmO5k+nTk= 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: List-Subscribe: List-Unsubscribe: > @@ -2327,7 +2330,8 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > struct mem_cgroup *memcg = lruvec_memcg(lruvec); > unsigned long anon_cost, file_cost, total_cost; > - int swappiness = mem_cgroup_swappiness(memcg); > + int swappiness = sc->swappiness ? > + *sc->swappiness : mem_cgroup_swappiness(memcg); > > Should we use "unlikely" here to indicate that sc->swappiness is an unexpected behavior? > Due to current use case only apply in proactive reclaim. On a system that is not under memory pressure, the rate of proactive reclaim could be higher than reactive reclaim. We should only use likely/unlikely when it's obvious a scenario will happen most of the time. I don't believe that's the case here. > > u64 fraction[ANON_AND_FILE]; > u64 denominator = 0; /* gcc */ > enum scan_balance scan_balance; > @@ -2608,6 +2612,9 @@ static int get_swappiness(struct lruvec *lruvec, struct scan_control *sc) > mem_cgroup_get_nr_swap_pages(memcg) < MIN_LRU_BATCH) > return 0; > > + if (sc->swappiness) > + return *sc->swappiness; > > Also there. > > + > return mem_cgroup_swappiness(memcg); > } > > @@ -6433,7 +6440,8 @@ unsigned long mem_cgroup_shrink_node(struct mem_cgroup *memcg, > unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg, > unsigned long nr_pages, > gfp_t gfp_mask, > - unsigned int reclaim_options) > + unsigned int reclaim_options, > + int *swappiness) > { > unsigned long nr_reclaimed; > unsigned int noreclaim_flag; > @@ -6448,6 +6456,7 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg, > .may_unmap = 1, > .may_swap = !!(reclaim_options & MEMCG_RECLAIM_MAY_SWAP), > .proactive = !!(reclaim_options & MEMCG_RECLAIM_PROACTIVE), > + .swappiness = swappiness, > }; > /* > * Traverse the ZONELIST_FALLBACK zonelist of the current node to put > -- > 2.34.1 > > My previous patch attempted to ensure fully deterministic semantics under extreme swappiness. > For example, when swappiness is set to 200, only anonymous pages will be reclaimed. > Due to code in MGLRU isolate_folios will try scan anon if no scanned, will try other type.(We do not want > it to attempt this behavior.) > How do you think about extreme swappiness scenarios? I think having different semantics between swappiness passed to proactive reclaim and global swappiness can be confusing. If it's needed to have a swappiness value that says "anon only no matter what", perhaps we should introduce such a new value and make it supported by both global and proactive reclaim swappiness? We could support writing "max" or something similar instead of a special value to mean that. Writing such value to global swappiness may cause problems and premature OOMs IIUC, but that would be misconfiguration. If we think that's dangerous, we can introduce this new value but make it valid only for proactive reclaim for now.