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 19F0BC433F5 for ; Tue, 8 Mar 2022 19:27:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82D748D0002; Tue, 8 Mar 2022 14:27:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DB7D8D0001; Tue, 8 Mar 2022 14:27:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A2538D0002; Tue, 8 Mar 2022 14:27:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 5BB808D0001 for ; Tue, 8 Mar 2022 14:27:52 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 24A7B20B15 for ; Tue, 8 Mar 2022 19:27:52 +0000 (UTC) X-FDA: 79222203984.08.E5D955F Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf20.hostedemail.com (Postfix) with ESMTP id 62D891C000D for ; Tue, 8 Mar 2022 19:27:51 +0000 (UTC) Received: by mail-qv1-f50.google.com with SMTP id gm1so236764qvb.7 for ; Tue, 08 Mar 2022 11:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Zl+fMccB1eQtSdhR7wsBcw8e5Fn8D32f7tn9xIP3WqM=; b=17MwfBSNl4Ojiq7W1yrsyU38u/AORq91f9I5tIy/g3RZvpvQvAyFWZRzL3RbKvLcGv l65OFZ+1OU8zRaS93UhS8vUm+MOK7iyLfAPOxJm4+fKF0ZJjixF6glXRf3NgXSWL4aAU Qzd1LSynsJG89zcZ7st0m3SCMQX1dRwCXY/ZkmDhCz1S3t2gafBi3f18/qj4cZ3m00EU qKsthqlXJMEeyKeKlNAukuR1YFt0MEMxQ/LUCPpU/9HBRENGpXKuC9HNkd2VWmP7MTpq ZON8ATND05sVQj79tyArh7/NXrTlIJGMCoJTATnY6+3fL7iKCFCJlr/JVe9M7SeIduOX j6tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Zl+fMccB1eQtSdhR7wsBcw8e5Fn8D32f7tn9xIP3WqM=; b=tDXI0f2lONZOVZrKQLh9kgTqsKswJi4iwjL6eAxTfS/YIDM0tWsftW+hPnSh/Y+HOW 7Rk+Tgx11WmzWnobCtl5W/V1tGzjG6uvjvE0KJOBl+IvsDbrcxhQRhL6DOh2uNTeJQBT Fl3JToouyWaptWSmjfLo9SKWAbsAtPmC2TSDRuQYdGwmbY0eWRmjt0cbESjmsyAm6xL6 Z0s5dnAuDgt/w3H4UNkJWyI98oWvM74sxzpjg/Jo9znzOraB77852XWJgIUrzUhryxmB a++O59aGmTwGioc/1DQRTl9SqiXLpoOyF1cs45VF2b0HKlcEmp/LWe71uJNaUSqcJjVR RrOA== X-Gm-Message-State: AOAM531oefJlUXTDQvr/IGixU0nmp1rBhNpKK8PQCJKaS6wXyDNaFDk6 tHRIYOqWAfFpHsCr6a0SYBv/Pg== X-Google-Smtp-Source: ABdhPJxhhJQ1qKgWTYu107vSLjLOywZQxEMagb+MyyCFJS8ZkSlhGUdLJfbxaZi3lStzrskLsT6/gQ== X-Received: by 2002:a05:6214:c63:b0:435:505f:ef32 with SMTP id t3-20020a0562140c6300b00435505fef32mr13571649qvj.62.1646767670601; Tue, 08 Mar 2022 11:27:50 -0800 (PST) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id w20-20020a05622a135400b002dd9806d532sm10727997qtk.54.2022.03.08.11.27.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 11:27:50 -0800 (PST) Date: Tue, 8 Mar 2022 14:27:49 -0500 From: Johannes Weiner To: Dan Schatzberg Cc: David Rientjes , Andrew Morton , Michal Hocko , Yu Zhao , Dave Hansen , linux-mm@kvack.org, Yosry Ahmed , Wei Xu , Shakeel Butt , Greg Thelen Subject: Re: [RFC] Mechanism to induce memory reclaim Message-ID: References: <5df21376-7dd1-bf81-8414-32a73cea45dd@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 62D891C000D X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=17MwfBSN; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.50 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Stat-Signature: 4utusifjkkha8nrnaf3eiou84wyngzpo X-HE-Tag: 1646767671-203323 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 Tue, Mar 08, 2022 at 09:49:20AM -0500, Dan Schatzberg wrote: > On Mon, Mar 07, 2022 at 03:50:36PM -0500, Johannes Weiner wrote: > > On Sun, Mar 06, 2022 at 03:11:23PM -0800, David Rientjes wrote: > > > - swappiness factor > > > > This I'm not sure about. > > > > Mostly because I'm not sure about swappiness in general. It balances > > between anon and file, but both of them are aged according to the same > > LRU rules. The only reason to prefer one over the other seems to be > > when the cost of reloading one (refault vs swapin) isn't the same as > > the other. That's usually a hardware property, which in a perfect > > world we'd auto-tune inside the kernel based on observed IO > > performance. Not sure why you'd want this per reclaim request. > > I think this could be useful for budgeting write-endurance. You may > want to tune down a workload's swappiness on a per-reclaim basis in > order to control how much swap-out (and therefore disk writes) its > doing. Right now the only way to control this is by writing to > vm.swappiness before doing the explicit reclaim which can momentarily > effect other reclaim behavior on the machine. Yeah the global swappiness setting is not ideal for tuning behavior of individual workloads. On the other hand, flash life and write budget are global resources shared by all workloads on the system. Does it make sense longer term to take a workload-centric approach to that? There are also filesystem writes to think about. If the swappable set has already been swapped and cached, reclaiming it again doesn't require IO. Reclaiming dirty cache OTOH requires IO, and upping reclaim pressure on files will increase the writeback flush rates (which reduces cache effectiveness and increases aggregate writes). I wonder if it would make more sense to recognize the concept of write endurance more broadly in MM code than just swap. Where you specify a rate limit (globally? with per-cgroup shares?), and then, yes, the VM will back away from swap iff it writes too much. But also throttle writeback and push back on file reclaim and dirtying processes in accordance with that policy.