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 C468BC433F5 for ; Sat, 16 Apr 2022 04:20:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 171E96B0072; Sat, 16 Apr 2022 00:20:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1206A6B0073; Sat, 16 Apr 2022 00:20:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2AB86B0074; Sat, 16 Apr 2022 00:20:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id E6DA46B0072 for ; Sat, 16 Apr 2022 00:20:30 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 99D938249980 for ; Sat, 16 Apr 2022 04:20:30 +0000 (UTC) X-FDA: 79361440620.27.3DE297A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 0DD3F20002 for ; Sat, 16 Apr 2022 04:20:29 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 85D2B6097A; Sat, 16 Apr 2022 04:20:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 500FEC385A3; Sat, 16 Apr 2022 04:20:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1650082827; bh=ndP7DnH+0uV9LgZ6UnXjtKlMPqFkQCYtGcMxI22lfkw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DngN/TqwEnTZN+jzz+HXCnHt18Ew6TbspwXKOFu6q4lTgpjzVgON0emfN4IrDsh3d VV0zjcuL0bs+J2ek9nDUp+l5YV4oSmn4vzoRaiBspjThPY8emzLVS0i0xxTT7yBFk1 Nsff9JX38lKG68EEayIJVXCzA/uZFf0ZXppn/4Xg= Date: Fri, 15 Apr 2022 21:20:24 -0700 From: Andrew Morton To: Yu Zhao Cc: Stephen Rothwell , Linux-MM , Andi Kleen , Aneesh Kumar , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , Holger =?ISO-8859-1?Q?Hoffst=E4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Subject: Re: [PATCH v10 12/14] mm: multi-gen LRU: debugfs interface Message-Id: <20220415212024.c682ac000e3e91572d8d6d2b@linux-foundation.org> In-Reply-To: References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-13-yuzhao@google.com> <20220411191634.674554d3de2ba37b3db40ca2@linux-foundation.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0DD3F20002 X-Stat-Signature: eprnapi4pio4bjikahufnqpf78jwp3f1 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="DngN/Tqw"; dmarc=none; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1650082829-529665 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 Fri, 15 Apr 2022 18:03:16 -0600 Yu Zhao wrote: > > Presumably sysfs is the place. Fully documented and with usage > > examples in the changelog so we can carefully review the proposed > > extensions to Linux's ABI. Extensions which must be maintained > > unchanged for all time. > > Eventually, yes. There still is a long way to go. Rest assured, this > is something Google will keep investing resources on. So. The plan is to put these interfaces in debugfs for now, with a view to migrating stabilized interfaces into sysfs (or procfs or whatever) once end-user requirements and use cases are better understood? If so, that sounds totally great to me. But it should have been in the darn changelog! This is the sort of thing which we care about most keenly. It would be helpful for reviewers to understand the proposed timeline for this process, because the entire feature isn't really real until this is completed, is it? I do think we should get this nailed down relatively rapidly, otherwise people will be reluctant to invest much into a moving target. And I must say, I see dissonance between the overall maturity of the feature as described in these emails versus the immaturity of these userspace control interfaces. What's happening there?