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 5C5C1C433FE for ; Sat, 12 Nov 2022 22:48:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64C816B0071; Sat, 12 Nov 2022 17:48:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FC4C8E0001; Sat, 12 Nov 2022 17:48:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49D0C6B0074; Sat, 12 Nov 2022 17:48:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 380DD6B0071 for ; Sat, 12 Nov 2022 17:48:53 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EE45F40465 for ; Sat, 12 Nov 2022 22:48:52 +0000 (UTC) X-FDA: 80126281704.20.5B44408 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf03.hostedemail.com (Postfix) with ESMTP id 499D320004 for ; Sat, 12 Nov 2022 22:48:52 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id k22so7887531pfd.3 for ; Sat, 12 Nov 2022 14:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pzirnVX9HS6ZZ0T+SA3bFsjzwhAronLKOoKxUZtrFJo=; b=psU90B9zyXa6xsHU9FdgbfSPEmFsooYJOggeAl1ZQjkfuNow9VsMs0h6zbt2KRJWHd dI/5PAt3ZJ4wjcLxzG33oQwHYrL4XMRg30LRP9ewmeWwwII6yS4EgY2i9RRCxkp+TFXB 31DDudEDsDOBIBkNUc7PbhLuP+Hn8jvjPDUYwoL+SVtPCsdQ2K/McCj3io/1D3BvS6eQ JatJfuQDp1Jle+1fXUEK0a+/9sHq4Jeu6uMn7kOCYexWd/Wt8LXUyIgKKdU6/k4FAPy9 qwfbb8EbliNUkACCmDn+lTnLbO22zdTJEx7aaP8KTb06+pgqQsuqoQaigiQy83hQBVBf WoCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pzirnVX9HS6ZZ0T+SA3bFsjzwhAronLKOoKxUZtrFJo=; b=hOA9XBmVSMp9Rh9hjqjmjM426/kd2HD4p8ZUBzuPsmRwlDPM3Lajh21QPmzic5OYtI ewvlTYr/ICPc5JkmS4lpqlPEFTibxNIqaRK2cQiHf9stWDCwZdJJnTnakdWZKvcRU2Wv 7g0jkPCPJnWQTHK6DnwujNEjJ/1J1TTYgU7Ynfr1kUcp3VcugHt4qgwVtiN3/mSBoJr7 jyOwDuyLB+3QiNVF8mY9TVU4IJbtjuumnLSJ0yEWnvL1JJBz4CZjJLuLpNTBYDD1pTAU LtLe9swJkixJ4DaEjWOUFo8vmNSG3mdgR/TNWcxIVZyTBrjLiuPbA4tSjMVgMYdToG61 XPcA== X-Gm-Message-State: ANoB5pnJRk1WhYPAZ4DG4mrAhkqPYj+qkzKqhQMkISQKvOPpcibc5I1z PKqhT7Lw1EVR2D2unUcw7+EU+Q== X-Google-Smtp-Source: AA0mqf4IyFCvPNuAHmmOus7KBjKRtXN6Hxrsd82gmp+O2SkfhS588FMd618vEdoUgvvoiF/KuPyZQQ== X-Received: by 2002:aa7:8656:0:b0:562:d99c:2f66 with SMTP id a22-20020aa78656000000b00562d99c2f66mr8200237pfo.42.1668293331106; Sat, 12 Nov 2022 14:48:51 -0800 (PST) Received: from localhost ([2620:10d:c090:400::5:54c6]) by smtp.gmail.com with ESMTPSA id f193-20020a6238ca000000b0056d2797bf05sm3739934pfa.217.2022.11.12.14.48.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Nov 2022 14:48:50 -0800 (PST) Date: Sat, 12 Nov 2022 17:48:54 -0500 From: Johannes Weiner To: Joonsoo Kim Cc: Andrew Morton , Mel Gorman , Hugh Dickins , Joonsoo Kim , Linux Memory Management List , LKML , kernel-team@fb.com Subject: Re: [PATCH] mm: vmscan: fix extreme overreclaim and swap floods Message-ID: References: <20220802162811.39216-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668293332; 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=pzirnVX9HS6ZZ0T+SA3bFsjzwhAronLKOoKxUZtrFJo=; b=JJ52yyHdCib2010yc2SrYSldZCMPh9IcXJ1cxSYEXCiaizE6UEHmdL1ebzIog+OwclvJnG +LySndveKxTxy/HjtpzJ3JPmkAUIwbiY5Vwyxs2HczIK7rroaCbsRmlxfF9/ypSbCGgRNP UBF+XdXOH51QK2Y0qD636CUqM2JaSDs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=psU90B9z; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668293332; a=rsa-sha256; cv=none; b=U1sm7LFvrr8QRxu6xa7NgmfJbMMF//b7hD5FVWm4J1Oq4i9oz7Z9nCu49wGhmhN+yz8C40 0NJqZ5cpazElZF1bYG6cEHSZ7MQS1cxHdkvToD3YhECL9yY3CtesjtNYesv/7+a5aCUPiJ ZFehejwjNlOVdW1FcoHAXU6njEqHpsg= X-Stat-Signature: 8ydcinmwpq6fe3ej58z3a9q7p7a4oc99 X-Rspamd-Queue-Id: 499D320004 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=psU90B9z; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.210.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1668293332-529597 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 Fri, Aug 12, 2022 at 10:59:12AM +0900, Joonsoo Kim wrote: > I think that we can fix the issue without breaking the fairness. > Key idea is that doing scan based on the lru having max scan count. > (aka max-lru) > As scan is doing on max-lru, do scan the proportional number of > pages on other lru. > > Pseudo code is here. > > 1. find the lru having max scan count > 2. calculate nr_to_scan_max for max-lru > 3. prop = (scanned[max-lru] + nr_to_scan_max) / targets[max-lru] What's nr_to_scan_max? AFAICS, prop would round down to 0 pretty quickly for imbalanced LRUs, at which point it would stop reclaiming the smaller list altogether. > 3. for_each_lru() > 3-1. nr_to_scan = (targets[lru] * prop) - scanned[lru] > 3-2. shrink_list(nr_to_scan) > > With this approach, we can minimize reclaim without breaking the > fairness. > > Note that actual code needs to handle some corner cases, one of it is > a low-nr_to_scan case to improve performance. Right. The main problem I see is that the discrepancies between LRU sizes can be many orders bigger than common reclaim goals. Even when one LRU is just 10x bigger, it'll be difficult to be both fair and still have efficient batch sizes when the goal is only 32 pages total. I think a proper way to do fairness would have to track scan history over multiple cycles. (I think mglru does that, but I can't be sure.)