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 E4F19C4332F for ; Thu, 14 Dec 2023 18:22:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 665CC8D00DB; Thu, 14 Dec 2023 13:22:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EE7C8D00C7; Thu, 14 Dec 2023 13:22:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FBAD8D00DB; Thu, 14 Dec 2023 13:22:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 217768D00C7 for ; Thu, 14 Dec 2023 13:22:36 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EE0EA4028F for ; Thu, 14 Dec 2023 18:22:35 +0000 (UTC) X-FDA: 81566244270.14.0B866E1 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf20.hostedemail.com (Postfix) with ESMTP id 2820F1C0008 for ; Thu, 14 Dec 2023 18:22:33 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FRBjDa4K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of schatzberg.dan@gmail.com designates 209.85.215.182 as permitted sender) smtp.mailfrom=schatzberg.dan@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702578154; 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=nW7YQuAxglqj6q/xmfwmVZsQUjHZQg8lnSbcIyJGzj0=; b=0dzBCkD8z/3ykz9ZY8krypVbpOFVS7NeRH9mBr3rKDblio7AdTy4RBny77SI0bYTDDoBZP lB1IbcMKw74FfPElpY5cTVTSuojw9elI8U8f/JzuxNaWd17ABayBfoegd3zGZXp7QVsWsM 8EPK7o6thjHu3Sd3xtro6d1b0IW4+vo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FRBjDa4K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of schatzberg.dan@gmail.com designates 209.85.215.182 as permitted sender) smtp.mailfrom=schatzberg.dan@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702578154; a=rsa-sha256; cv=none; b=zf+YhzDPn3fCP01JSzcq5hACrJpxQ47laFbr1g3TcvCjgDrqZyfLgDVOJYELO0mONOC0uI IjoujQJrT6hMjMCofXthnrTDECy1IP9THBLRmg0migpE1JPr1dR069WzBJ/9KoJIF33BQJ zUX5E0abQfJpIzLBtZ9yvRBbd5ucjyM= Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-53fbf2c42bfso7011958a12.3 for ; Thu, 14 Dec 2023 10:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702578153; x=1703182953; darn=kvack.org; 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=nW7YQuAxglqj6q/xmfwmVZsQUjHZQg8lnSbcIyJGzj0=; b=FRBjDa4KE5qpYDYFqwJGbZNPAJe+szdpnHCReyEznhfynHyvws27kCmm9VstXjU2pr YhSOvJE/hOtwCFZ0+V41rz2DTY5mapYtACCsn+3YdSi441x9pfIS/ZD4KvmG3CdtYSLF HQOCEg2SaXsdvza0vjY64cl4098PzQ2Lix+aSF+qM4RGfErHgzLLvC4uXF2MRW4ze1YO FjFdNPYUbJDnaWyJ+knNwK+ZJb9YVot8K6/15b+N7SUoTHhp0UTFBxknCzmEvKKTi85M 5EI1xwjFD+GdgKoT1pofjGfIyaI9TO1mXQUORoGAS1ttVTPDre4zr3k3H7AeN5IKCvjY dMyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702578153; x=1703182953; 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=nW7YQuAxglqj6q/xmfwmVZsQUjHZQg8lnSbcIyJGzj0=; b=Bkcz+0DGhmz5bhU0r1LDIrjJcVz+OB5hCmR17r5V/VTNb8JAxP+eciH6oPchEb2zRo z71iBAHNRQmMi6NgaaeCPdMWVhNuCSz/Mx+3bO9/3UGUJ/bH7Wel1PEtUcf9DAf2OaA9 wffbref4F293oq4odLj73j3Rbxfb2YLYBY7jBRRNy3vP6LIgCxWJokrk4pK6CfpPb9xb IIOUSmYbGmST7uHAaRBT9N43plQ/TLsnPRazwmtGcAPDLIpgFjap5YCOoR+VR9tlZ788 YQ/084i9wkmb6cbjBzDVmaErQH2ZdgyBUwTDKcfCpEsCSqivTvDnYcAVZklbXXVazyc6 g2lw== X-Gm-Message-State: AOJu0Yxk95jWz8jRZc4JI+jAEA2O4vtyVmUZ1fFZKnav38kgJfCDVUpK DPQyscKlxnE2ijpyUZ9iAD8= X-Google-Smtp-Source: AGHT+IFSWzhP+yJbXjLlek3YaFccxzQV2Fb8vWZD7aBS7ToIo7bB/MXO3R2XPy8zYxYUW47oQo7cIQ== X-Received: by 2002:a17:902:7842:b0:1d0:b229:faa2 with SMTP id e2-20020a170902784200b001d0b229faa2mr8048916pln.68.1702578152753; Thu, 14 Dec 2023 10:22:32 -0800 (PST) Received: from dschatzberg-fedora-PF3DHTBV ([2620:10d:c090:500::5:223d]) by smtp.gmail.com with ESMTPSA id iz5-20020a170902ef8500b001cfcf3b6de7sm3559334plb.52.2023.12.14.10.22.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Dec 2023 10:22:32 -0800 (PST) Date: Thu, 14 Dec 2023 13:22:29 -0500 From: Dan Schatzberg To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Yosry Ahmed , Huan Yang , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Tejun Heo , Zefan Li , Jonathan Corbet , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Kefeng Wang , Yue Zhao , Hugh Dickins Subject: Re: [PATCH V4 2/2] mm: add swapiness= arg to memory.reclaim Message-ID: References: <20231213013807.897742-1-schatzberg.dan@gmail.com> <20231213013807.897742-3-schatzberg.dan@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 4pkjn46sncuxw9b4taax357srwoo18p9 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 2820F1C0008 X-HE-Tag: 1702578153-695454 X-HE-Meta: U2FsdGVkX19KR+rschYaZVLygDKlJO385/HHzcdKwUwDrxNwYysmELRfOzkQ72qN8STkrOty6jacFd3KEDc9TFKm/t+WQhp5oXdvInO8Tg7QPUrBeDbohE78x9EYqj8P0sPQnclrDshZTbaUzg5/620vMYLtqEwoBLEoishBu9N0l86Zd1MJ+qjAdzF8CtzABN75VufFGKnuNTVVwEB7YkWgcnYbTg5fUvKlFbnN8WYX999XJdl0trjntLLMbu7Io2ih6miLF3Of6q6EXFx00R9zNBfhjHHppH7nsRhx0ZGZI8VvxrK76zmrqOnjHMQWB32GoAoTBxrtY3bcTomaNmW49RKEyqWFrduw1VfNelVLw2h9br26ApZmRZe+wVhgPf2LO/W/S756v8YmRHm9Q3uB9ktfi6KPDsxIK+P3QbbMngJwMNOxqhAnRnRd0eCUwAO4yRGNuNRs/vK4YIiyEDjT7zUBxVDdHHkSLUsfHx8VLduMLKTropBRVjeXDmM4lIbHF+Hx1GMntJ4oStKe7fr8LEXqGwqzh40uVwSmhAy9xHnFUYUK7pSMU5C7ceDVcOW6aGCy6CBr2IHPs6WcwlptW9oWLJYZf6rS+NQ3UYOPIe9CZBhmYGBBqUJ9HalSav+PUgxDVVmcy14GF8peERVHfQNV67WKtKWyrE7MKZD/aL2r+pirSx9e9x/IxYl3rhnkgNqLVrTVvax1KRJ2psRKTSK3V0g4TxJ3kZ+wGLFnQS8m581fdeWtYnCc/Me9r9t2U/OmJkOjnMgAcGIWNzQQjs+q5BTwB0cpDavVUJTaJFrhAa9ZoJxBq1BI8noUoY/9Cb0d/txLAt9/ZE4dNg6GMTrbKXtsdu7CSuBgCKP9t5/nyRvJej3vh+KtGaLEbHU1fraYSYaPPadzSLJOh/cm8shEXqpB/W2AFeRnSYgzctoXeK7Ymv2/jNDa5Q5pdwUDjGt/RdXtiqMMNr3 I9m8GIFv UanQWQdT77mrJd+0Vumlhl1GGp98xHjCgvFLkKmYKkWG70OxbcL0dHCW/L+/Br9YDywdzRR3fDqXSDwyMaTyWfmIItUdRRNcol2e92zsS2QKwajt3N+fe+MmXjMlOMWAQiJtqodk1lkUrYM97ewU6MXu1bZtWMh3SddkssApCZZZAESmwwp3NE2tIJPRHQyA9oR5Anaa9vDYvf4KFWqaJz7WDdeuamsk7Y7cAx3srHblqMPqAV6sU4PFTd0RFbuGsNP8muMSowcQBjzBiiA2YcqixxNXtyHWIraBxQWdVqLLsq3mvOF0M3gVcv46nKmQ+2aLybWQgJXpW1wHOdUqGhUsJ7U4H7yrVqIBmPoztso5xQQm/DSSPvWZ6AqO7yVujczWhj/KwVx4blJg75Xf9N2+eBaJ5p1hNfmFeoDvOli0sDlrn+C+SHf0A2IumLvujH1KktalcXNLSHKyP5C1EVDbfhEzESCbdzyDFZKuVI17Q09n3KwPHBUnptHYXnuktGApUny+Zpvl12CN3oNHoM/02geqrwGuR2ZtXlLoKC8Elyzk= 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: On Thu, Dec 14, 2023 at 09:38:55AM +0100, Michal Hocko wrote: > On Tue 12-12-23 17:38:03, Dan Schatzberg wrote: > > Allow proactive reclaimers to submit an additional swappiness= > > argument to memory.reclaim. This overrides the global or per-memcg > > swappiness setting for that reclaim attempt. > > You are providing the usecase in the cover letter and Andrew usually > appends that to the first patch in the series. I think it would be > better to have the usecase described here. > > [...] > > @@ -1304,6 +1297,18 @@ PAGE_SIZE multiple when read back. > > This means that the networking layer will not adapt based on > > reclaim induced by memory.reclaim. > > > > +The following nested keys are defined. > > + > > + ========== ================================ > > + swappiness Swappiness value to reclaim with > > + ========== ================================ > > + > > + Specifying a swappiness value instructs the kernel to perform > > + the reclaim with that swappiness value. Note that this has the > > + same semantics as the vm.swappiness sysctl - it sets the > > same semantics as vm.swappiness applied to memcg reclaim with all the > existing limitations and potential future extensions. Thanks, will make this change. > > > + relative IO cost of reclaiming anon vs file memory but does > > + not allow for reclaiming specific amounts of anon or file memory. > > + > > memory.peak > > A read-only single value file which exists on non-root > > cgroups. > > The biggest problem with the implementation I can see, and others have > pointed out the same, is how fragile this is. You really have to check > the code and _every_ place which defines scan_control to learn that > mem_cgroup_shrink_node, reclaim_clean_pages_from_list, > reclaim_folio_list, lru_gen_seq_write, try_to_free_pages, balance_pgdat, > shrink_all_memory and __node_reclaim. I have only checked couple of > them, like direct reclaim and kswapd and none of them really sets up > swappiness to the default memcg nor global value. So you effectively end > up with swappiness == 0. > > While the review can point those out it is quite easy to break and you > will only learn about that very indirectly. I think it would be easier > to review and maintain if you go with a pointer that would fallback to > mem_cgroup_swappiness() if NULL which will be the case for every > existing reclaimer except memory.reclaim with swappiness value. I agree. My initial implementation used a pointer for this reason. I'll switch this back. Just to be clear - I still need to initialize scan_control.swappiness in all these other places right? It appears to mostly be stack-initialized which means it has indeterminate value, not necessarily zero.