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 C73A6C433EF for ; Tue, 17 May 2022 20:45:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDA596B0074; Tue, 17 May 2022 16:45:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E89636B0075; Tue, 17 May 2022 16:45:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D511A6B0078; Tue, 17 May 2022 16:45:51 -0400 (EDT) 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 C1AA06B0074 for ; Tue, 17 May 2022 16:45:51 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 88FFE20BE4 for ; Tue, 17 May 2022 20:45:51 +0000 (UTC) X-FDA: 79476416502.25.211601B Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf30.hostedemail.com (Postfix) with ESMTP id 9B203800C8 for ; Tue, 17 May 2022 20:45:27 +0000 (UTC) Date: Tue, 17 May 2022 13:45:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1652820349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Em8NsZUR8JQ7Gugh2/gtd6noWd4WuWBv2BitYZODNhk=; b=gzIje8V5/YcreFfY/XovYcV9/bRe+Q+bz7ix4NVeJbUGrDDGGKXA6P1dVzhpOYec180+j1 687rvJUDXF+QWBXpMR9zbz3liFxyDGztBFNH/KvWQ5pdpm0KVoHYUpWWXSrliTCmmhEmtG Uj3MXGL4v/J5MCUfWT6Ey4xVnycj/4w= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Yosry Ahmed Cc: Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , cgroups@vger.kernel.org, Tejun Heo , Linux-MM , Yu Zhao , Wei Xu , Greg Thelen , Chen Wandun Subject: Re: [RFC] Add swappiness argument to memory.reclaim Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Stat-Signature: 56unn5xm6zifokcms3gf9ueztkmizjnq Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gzIje8V5; spf=pass (imf30.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 9B203800C8 X-HE-Tag: 1652820327-16329 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, May 17, 2022 at 01:11:13PM -0700, Yosry Ahmed wrote: > On Tue, May 17, 2022 at 12:49 PM Roman Gushchin > wrote: > > > > On Tue, May 17, 2022 at 11:13:10AM -0700, Yosry Ahmed wrote: > > > On Tue, May 17, 2022 at 9:05 AM Roman Gushchin wrote: > > > > > > > > On Mon, May 16, 2022 at 03:29:42PM -0700, Yosry Ahmed wrote: > > > > > The discussions on the patch series [1] to add memory.reclaim has > > > > > shown that it is desirable to add an argument to control the type of > > > > > memory being reclaimed by invoked proactive reclaim using > > > > > memory.reclaim. > > > > > > > > > > I am proposing adding a swappiness optional argument to the interface. > > > > > If set, it overwrites vm.swappiness and per-memcg swappiness. This > > > > > provides a way to enforce user policy on a stateless per-reclaim > > > > > basis. We can make policy decisions to perform reclaim differently for > > > > > tasks of different app classes based on their individual QoS needs. It > > > > > also helps for use cases when particularly page cache is high and we > > > > > want to mainly hit that without swapping out. > > > > > > > > > > The interface would be something like this (utilizing the nested-keyed > > > > > interface we documented earlier): > > > > > > > > > > $ echo "200M swappiness=30" > memory.reclaim > > > > > > > > What are the anticipated use cases except swappiness == 0 and > > > > swappiness == system_default? > > > > > > > > IMO it's better to allow specifying the type of memory to reclaim, > > > > e.g. type="file"/"anon"/"slab", it's a way more clear what to expect. > > > > > > I imagined swappiness would give user space flexibility to reclaim a > > > ratio of file vs. anon as it sees fit based on app class or userspace > > > policy, but I agree that the guarantees of swappiness are weak and we > > > might want an explicit argument that directly controls the return > > > value of get_scan_count() or whether or not we call shrink_slab(). My > > > fear is that this interface may be less flexible, for example if we > > > only want to avoid reclaiming file pages, but we are fine with anon or > > > slab. > > > Maybe in the future we will have a new type of memory to > > > reclaim, does it get implicitly reclaimed when other types are > > > specified or not? > > > > > > Maybe we can use one argument per type instead? E.g. > > > $ echo "200M file=no anon=yes slab=yes" > memory.reclaim > > > > > > The default value would be "yes" for all types unless stated > > > otherwise. This is also leaves room for future extensions (maybe > > > file=clean to reclaim clean file pages only?). Interested to hear your > > > thoughts on this! > > > > The question to answer is do you want the code which is determining > > the balance of scanning be a part of the interface? > > > > If not, I'd stick with explicitly specifying a type of memory to scan > > (and the "I don't care" mode, where you simply ask to reclaim X bytes). > > > > Otherwise you need to describe how the artificial memory pressure will > > be distributed over different memory types. And with time it might > > start being significantly different to what the generic reclaim code does, > > because the reclaim path is free to do what's better, there are no > > user-visible guarantees. > > My understanding is that your question is about the swappiness > argument, and I agree it can get complicated. I am on board with > explicitly specifying the type(s) to reclaim. I think an interface > with one argument per type (whitelist/blacklist approach) could be > more flexible in specifying multiple types per invocation (smaller > race window between reading usages and writing to memory.reclaim), and > has room for future extensions (e.g. file=clean). However, if you > still think a type=file/anon/slab parameter is better we can also go > with this. If you allow more than one type, how would you balance between them? E.g. in your example: $ echo "200M file=no anon=yes slab=yes" > memory.reclaim How much slab and anonymous memory will be reclaimed? 100M and 100M? Probably not (we don't balance slabs with other types of the memory). And if not, the interface becomes very vague: all we can guarantee is that *some* pressure will be applied on both anon and slab. My point is that the interface should have a deterministic behavior and not rely on the current state of the memory pressure balancing heuristic. It can be likely done in different ways, I don't have a strong opinion here. Thanks!