[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c18e273b-f30c-da5c-581b-0cc4672f4481@intel.com>
Date: Mon, 2 May 2022 08:20:45 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Wei Xu <weixugc@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Huang Ying <ying.huang@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Yang Shi <shy828301@...il.com>, Linux MM <linux-mm@...ck.org>,
Greg Thelen <gthelen@...gle.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
Jagdish Gediya <jvgediya@...ux.ibm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alistair Popple <apopple@...dia.com>,
Davidlohr Bueso <dave@...olabs.net>,
Michal Hocko <mhocko@...nel.org>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Brice Goglin <brice.goglin@...il.com>,
Feng Tang <feng.tang@...el.com>, Jonathan.Cameron@...wei.com
Subject: Re: RFC: Memory Tiering Kernel Interfaces
> The current memory tiering interface needs to be improved to address
> several important use cases:
FWIW, I totally agree. We knew when that code went in that the default
ordering was feeble. There were patches to export the demotion order
and allow it to be modified from userspace, but they were jettisoned at
some point.
> Memory tiering hierarchy is rebuilt upon hot-add or hot-remove of a
> memory node, but is NOT rebuilt upon hot-add or hot-remove of a CPU
> node.
Yeah, this would be a welcome improvement if we can get there.
> * /sys/devices/system/node/memory_tiers
>
> Format: node list (one tier per line, in the tier order)
>
> When read, list memory nodes by tiers.
Nit: this would seems to violate the one-value-per-file sysfs guideline.
It can be fixed by making tiers actual objects, which would have some
other nice benefits too.
Powered by blists - more mailing lists