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 73FA4C433EF for ; Fri, 1 Apr 2022 21:22:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 974C18D0002; Fri, 1 Apr 2022 17:22:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FB758D0001; Fri, 1 Apr 2022 17:22:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 775D58D0002; Fri, 1 Apr 2022 17:22:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 670CC8D0001 for ; Fri, 1 Apr 2022 17:22:08 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 2DD8C82295 for ; Fri, 1 Apr 2022 21:21:58 +0000 (UTC) X-FDA: 79309582716.11.A984352 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf22.hostedemail.com (Postfix) with ESMTP id 88136C001D for ; Fri, 1 Apr 2022 21:21:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1648848115; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RheG54Ou/GCQ9HYC/0tkyW4FKtlSnlhACvpquuW6JiY=; b=C9f2RCuoO8F6qaHAYQpqz7jL5PucFQfwU/3ammN/mL2rYcntPCt7BTtkpbezWZSwxFr7A6 mf+PgUfJRw4OntsGYKHLRPjtjRq0oX8YZ4BQ/GmKn5N5YMAho3xAZY/Ols+1fVA3dou8ph O01NqbVchl5UCEMLOAf4yCTprThcg/Q= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin In-Reply-To: Date: Fri, 1 Apr 2022 14:21:52 -0700 Cc: Yosry Ahmed , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Linux-MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Wei Xu , Greg Thelen Message-Id: <243A0156-D26A-47C9-982A-C8B0CDD69DA2@linux.dev> References: To: Johannes Weiner X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Rspam-User: X-Stat-Signature: 5yp3pzm6xee3c6o1aupj38h7kd84nsmw Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=C9f2RCuo; spf=pass (imf22.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-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 88136C001D X-HE-Tag: 1648848117-872475 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 Apr 1, 2022, at 2:13 PM, Johannes Weiner wrote: >=20 > =EF=BB=BFOn Fri, Apr 01, 2022 at 11:39:30AM -0700, Roman Gushchin wrote: >> The interface you're proposing is not really extensible, so we'll likely n= eed to >> introduce a new interface like memory.reclaim_ext very soon. Why not crea= te >> an extensible API from scratch? >>=20 >> I'm looking at cgroup v2 documentation which describes various interface f= iles >> formats and it seems like given the number of potential optional argument= s >> the best option is nested keyed (please, refer to the Interface Files sec= tion). >>=20 >> E.g. the format can be: >> echo "1G type=3Dfile nodemask=3D1-2 timeout=3D30s" > memory.reclaim >=20 > Yeah, that syntax looks perfect. >=20 > But why do you think it's not extensible from the current patch? We > can add those arguments one by one as we agree on them, and return > -EINVAL if somebody passes an unknown parameter. >=20 > It seems to me the current proposal is forward-compatible that way > (with the current set of keyword pararms being the empty set :-)) It wasn=E2=80=99t obvious to me. We spoke about positional arguments and the= n it wasn=E2=80=99t clear how to add them in a backward-compatible way. The l= ast thing we want is a bunch of memory.reclaim* interfaces :) So yeah, let=E2=80=99s just describe it properly in the documentation, no co= de changes are needed.=