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 62810C4706C for ; Tue, 9 Jan 2024 23:54:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7CC16B00B7; Tue, 9 Jan 2024 18:54:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D03476B00B8; Tue, 9 Jan 2024 18:54:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B63F46B00B9; Tue, 9 Jan 2024 18:54:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9B2AF6B00B7 for ; Tue, 9 Jan 2024 18:54:56 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 611C6120A66 for ; Tue, 9 Jan 2024 23:54:56 +0000 (UTC) X-FDA: 81661430592.19.E566BC2 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf23.hostedemail.com (Postfix) with ESMTP id 8DB2B140003 for ; Tue, 9 Jan 2024 23:54:54 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=An9o+7r5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704844494; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s8TS1nLrUKAIFkkWa3SxEx8yDQZVgIO6/irtFJFIovg=; b=4Ltnn37LZLhCaQxAWio//sp6cpw9BwC+WF6ne1QwYpPkNp2GPNb4qr/sFnkmxXjV1yX0k8 MqRVPS6cBQ6pXTKakbOnJ2ZwqBEtNYIr14KMTqwvICBRn+fC3uR1qcXcUnJOhTk8XfjSIz Z6ns6j5byLX1MvA1nhh+MXP8q45otIU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=An9o+7r5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704844494; a=rsa-sha256; cv=none; b=TQlQVQNNI2pCY6hScAcxiQrum5d5LgijEs7PSIIRlLPIVFr5QLVJGYPWkhwP/+y9r840Cy Q4meCWChjEkAoia+p9LoHmYX1bmejUb9drqKPMzFj61IOxLje+KTgzaVu3hA2vXXxn/yGN RqWhtAzbRYrrO/wiepuQ/GBmoAB2lfg= Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-40e4a606183so21175e9.0 for ; Tue, 09 Jan 2024 15:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704844493; x=1705449293; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=s8TS1nLrUKAIFkkWa3SxEx8yDQZVgIO6/irtFJFIovg=; b=An9o+7r5EU6s3Z6G9oiPQVPKdez+Y/0UhjaQyip3lZbzzxg7Y9gstkmXpJBAT/7dHI +FKuj2VTFoeDlalWHVvF/L7sXj1ZBhUh+UQEJDqoIWyotaKbEq0LbJ/dA3FeuL2mFexP 5AgI3O9UszFocxlOLxZMLr6G1w/B/bPOh5wllehAeJ7mru8rihxUcWm74rbtfsiz8JHg TJaRzb92EowkvMj61vXNX7UjuCHEFNodtL2BojEob6dtxnBtClxrpIn4HCtu3+hc1zva rYa2DtM10J/ZLI7xE4oscynUK8OdPMbdnN27RzX/xb2HHUWYaHp6oyUp32XRNUuoR0zk SFKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704844493; x=1705449293; h=content-transfer-encoding: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=s8TS1nLrUKAIFkkWa3SxEx8yDQZVgIO6/irtFJFIovg=; b=LK8bIj1TneLLS3WFDGKIWd+nm+crBH9ChiyjBP2wsorTcCzZpOVtp1VGQI3rvQvVPn E1xjF8e1n6xyz7QpUNDQRDrc0kdco8u7qfsnZ76eCew6amTaQ3MzDfVFeDDIH7KhpQzL NNCtkzz9h6EkTgMBjASWU5OOz95kEe9a0jKQZkeXmAHxX+C0NtGp+c68X6Ojoyysf5TL omNTocM1ziW2gLU5/EaC6nAfRRd9o+SnjcaNw8OTrOC/ccjf/M7Hs7lw76/JGPPPA8XR 0nJk8zT4SLFYZZElZigKKR8THbR4mFF4u1G1ARRPGyuuXxl3ZCY5zCk3cnVA/aqBxzpe kDTg== X-Gm-Message-State: AOJu0Yzy5Wl5KaqHZlG+9NRMZ2XhgtnPEB0uvIBD07glC33DVtQ1wrAe 8YqhQKzDl4wbQn1Z0U5oPtiA6Nrqvj1Yg6OUoOgzAcxX7i7v X-Google-Smtp-Source: AGHT+IHnVyCz6SSfqCzYFM+Jm12othHqlyx9vavQpdTKez22yrHgvpFo4duCvDoolAcTA2kj8bvDBtUqSdv5GmLPHQM= X-Received: by 2002:a05:600c:5118:b0:40d:887b:6979 with SMTP id o24-20020a05600c511800b0040d887b6979mr102042wms.0.1704844492708; Tue, 09 Jan 2024 15:54:52 -0800 (PST) MIME-Version: 1.0 References: <20240103164841.2800183-1-schatzberg.dan@gmail.com> <20240103164841.2800183-3-schatzberg.dan@gmail.com> In-Reply-To: From: Yu Zhao Date: Tue, 9 Jan 2024 16:54:15 -0700 Message-ID: Subject: Re: [PATCH v6 2/2] mm: add swapiness= arg to memory.reclaim To: Michal Hocko Cc: Dan Schatzberg , Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Yosry Ahmed , David Rientjes , Chris Li , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Roman Gushchin , Shakeel Butt , Muchun Song , David Hildenbrand , Matthew Wilcox , Kefeng Wang , Yue Zhao , Hugh Dickins Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8DB2B140003 X-Stat-Signature: dqh883yyz66s5ueqxyzrnhnojf5g3rgx X-Rspam-User: X-HE-Tag: 1704844494-235365 X-HE-Meta: U2FsdGVkX1+BIFsFjKPSF2var6HiAtxTy6OojnRte3mCRueLNGSKQRZmyQ3Udt4RY0F0dNW+btnPgZG1xI8lSpYBbjz4l7yx+K9G7X+WgYrt2R5Qv3zki+LtEDTjC+CcIkwCPIlXMQSQhzxIT68ThPAc5nUnRqpdyshYnkoTgzFWhXn/B5rMIbAgj6XUIEUvcxpaLCxtEVU4wdWaSyybsPwGhMO8URcBhIAUbjOKhQZnEokoA1URcFjUyGpc5Fxk/QigpHYMcFTvn2uwGdc0Bw4p2inTVt4RXHKFsH0bdC9vYFA50hjCYZnZpCQ3IZ3jcgzqdbOFbpTZzXl5oRaiNs6hNgrWyscQuEEfCbUANz8wdU8bsmLbWPokBxp7WUrr5VITOLs3HADhSVClMsXGREHDHVCS1lpHEm7UV+U7HbuXrj37DJSjmrwmSl4TPgVlWhPDCYSGU2gRqjrRFdQJUnLjqt4FrkY9SePaEkW/VEQiXdCQghCOSC3KYMSLjThKIh10mY8lrolUJTmlLW736wzqXd2t0d0r5uV+9mHfHaw5SvUQ/z0kQS6JLD/YlEDyqhY73aL7R2bRrRdeaAwwubSZzBcIqK2qgcTwJL2KqO4NUG5U6ovocZIRYnQMFZjk+oTLDmpvrCzhId+pn23/2+4Yt77s/bpSR3RcO1R23SX2WA3zRRnCTmFqIhu0VUK+848EbnZHeUknWpLd9KJ08j1eOOTcbemcNVEEsQnmNsK9wd1Z4/seAIsmP2/xmO7C9OjrsgU06KP7e3dTOypxDvrnc2PbrsyIMb48h6X0Jt20XBhHpCr97IrVyMr/N4tlmP2RnmhcAvIe+cDnJLeWTgEyaAXYCIE7qFES8n6O3Sgno3Dg1B/6QqNW7xP1F1ytU81+JI20cnyc5uHirWWy65xsKTrlWMn35JW6o0FGHd5oHJkdCHgtRffiN4LDmWJHPXn3fLPnJ1sfN188oe1 KsUTDu0n 2O7mEBiYrBdI0g/Z7Aqw8OJSkp1myHxk0Cxl4fdDbV/lA7xqHLgQkrWSRhVl0ZfId3Ly5V0LfjMfyGJyP3RwapbD1ZWBqDweaPWYR60uJ6gfXNX+iCCQ21/mRXPo58b7CUisl9qCSxSmQkZH7X0sd62xqHCm9xc3wbY+uCgKwwBKQZaNud9CfOGs7uGSbAx4NYNo+wfkTgmzLNhvyllr7DoqQW2RC8p3HfzImTMLpzLKxAmMqAH7bZwVhBC7utXmX46PGpc/KD/8DbUZBQqD3KqUPZqkPhHqJPVgbudkk8qRKctZjR6Eb7CXYMfgQD7Vb1YpTQ/4eaW5X7Um1gO9THSLUnYDRe+hLJioFj/oXLJM1oeOs7ytHDWijx/I3c92JXiD+bBjmebXV9blExdvPt5AXFeTnFJg7DDLv 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, Jan 4, 2024 at 1:48=E2=80=AFAM Michal Hocko wrote= : > > On Wed 03-01-24 18:07:43, Yu Zhao wrote: > > On Wed, Jan 03, 2024 at 01:19:59PM -0500, Dan Schatzberg wrote: > > > On Wed, Jan 03, 2024 at 10:19:40AM -0700, Yu Zhao wrote: > > > [...] > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > > > index d91963e2d47f..394e0dd46b2e 100644 > > > > > --- a/mm/vmscan.c > > > > > +++ b/mm/vmscan.c > > > > > @@ -92,6 +92,11 @@ struct scan_control { > > > > > unsigned long anon_cost; > > > > > unsigned long file_cost; > > > > > > > > > > +#ifdef CONFIG_MEMCG > > > > > + /* Swappiness value for proactive reclaim. Always use sc_= swappiness()! */ > > > > > + int *proactive_swappiness; > > > > > +#endif > > > > > > > > Why is proactive_swappiness still a pointer? The whole point of the > > > > previous conversation is that sc->proactive can tell whether > > > > sc->swappiness is valid or not, and that's less awkward than using = a > > > > pointer. > > > > > > It's the same reason as before - zero initialization ensures that the > > > pointer is NULL which tells us if it's valid or not. Proactive reclai= m > > > might not set swappiness and you need to distinguish swappiness of 0 > > > and not-set. See this discussion with Michal: > > > > > > https://lore.kernel.org/linux-mm/ZZUizpTWOt3gNeqR@tiehlicka/ > > > > static ssize_t memory_reclaim(struct kernfs_open_file *of, char *buf, > > size_t nbytes, loff_t off) > > { > > struct mem_cgroup *memcg =3D mem_cgroup_from_css(of_css(of)); > > unsigned int nr_retries =3D MAX_RECLAIM_RETRIES; > > unsigned long nr_to_reclaim, nr_reclaimed =3D 0; > > + int swappiness =3D -1; > > ... > > reclaimed =3D try_to_free_mem_cgroup_pages(memcg, > > min(nr_to_reclaim - nr_reclaime= d, SWAP_CLUSTER_MAX), > > - GFP_KERNEL, reclaim_options); > > + GFP_KERNEL, reclaim_options, > > + swappiness); > > > > ... > > > > +static int sc_swappiness(struct scan_control *sc, struct mem_cgroup *m= emcg) > > +{ > > + return sc->proactive && sc->proactive_swappiness > -1 ? > > + sc->proactive_swappiness : mem_cgroup_swappiness(memcg); > > +} > > Tpo be completely honest I really fail to see why this is such a hot > discussion point. To be completely clear both approaches are feasible. Feasible but not equal. > The main argument for NULL check based approach is that it is less error > prone from an incorrect ussage because any bug becomes obvious. Any bug becomes *fatal*, and fatal isn't only obvious but also hurts in production systems. This was the reason for going through the trouble switching from VM_BUG_ON() to VM_WARN_ON() and documenting it in Documentation/process/coding-style.rst: 22) Do not crash the kernel --------------------------- In general, the decision to crash the kernel belongs to the user, rather than to the kernel developer. Isn't? > If we > use any other special constant a missing initialization would be much > harder to spot because they would be subtle behavior change. > > Are there really any strong arguments to go against this "default > initialization is safe" policy? Just wanted to point out an alternative. Fine details (best practices) matter to me.