On Tue, Apr 26, 2022 at 3:30 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 26 Apr 2022 00:59:37 -0600 Yu Zhao <yuzhao@xxxxxxxxxx> wrote: > > > On Fri, Apr 15, 2022 at 10:20 PM Andrew Morton > > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, 15 Apr 2022 18:03:16 -0600 Yu Zhao <yuzhao@xxxxxxxxxx> 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? > > > > The requirements are well understood and the use cases are proven, > > e.g., Google [1], Meta [2] and Alibaba [3]. > > > > [1] https://dl.acm.org/doi/10.1145/3297858.3304053 > > [2] https://dl.acm.org/doi/10.1145/3503222.3507731 > > [3] https://gitee.com/anolis/cloud-kernel/blob/release-5.10/mm/kidled.c > > So will these interfaces be moved into sysfs? So the debugfs interface from this patch provides: 1. proactive reclaim, 2. working set estimation. The sysfs interface for item 1 is being finalized by [4], and it's a subset of this debugfs interface because we want it to be more general. The sysfs interface for item 2 will be eventually proposed as well, with the same approach. It will look like a histogram in which the active/inactive LRU has two bins whereas MGLRU has more bins. Bins contain pages and multiple bins represent different hotness/coldness. Since [4] took about two years, I'd say this histogram-like interface would take no less than a couple of years as well. This debugfs interface stays even after that, and it will serve its true purpose (debugging), not a substitute for the sysfs interfaces. > > > 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? > > > > Very observant. To answer both of the questions above: each iteration > > of the entire stack is a multi-year effort. > > > > Given its ROI, companies I know of constantly pour money into this > > area. Given its scale, this debugfs is the least of their concerns. A > > good example is the proactive reclaim sysfs interface [4]. It's been > > used at Google for many years and at Meta for a few years. We only > > started finalizing it recently. > > > > [4] https://lore.kernel.org/r/20220425190040.2475377-1-yosryahmed@xxxxxxxxxx/ > > Sure, if one organization is involved in both the userspace code and > the kernel interfaces then the alteration of kernel interfaces can be > handled in a coordinated fashion. > > But releasing interfaces to the whole world is a different deal. It's > acceptable to say "this is in debugfs for now because it's a work > in progress" but it sounds like mglru's interfaces are beyond that > stage? Correct. It's a WIP in the sense of "know what needs to be done but can't get it done immediately", not "don't know what's next; try this for now".
