Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAAPL-u9sVx94ACSuCVN8V0tKp+AMxiY89cro0japtyB=xNfNBw@mail.gmail.com>
 <c18e273b-f30c-da5c-581b-0cc4672f4481@intel.com>
In-Reply-To: <c18e273b-f30c-da5c-581b-0cc4672f4481@intel.com>
From:   Wei Xu <weixugc@google.com>
Date:   Tue, 3 May 2022 00:19:01 -0700
Message-ID: <CAAPL-u8TtNoonOBDU1HZ-XPA31zsDvDAnO2xDigApypX-+jTYA@mail.gmail.com>
Subject: Re: RFC: Memory Tiering Kernel Interfaces
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Huang Ying <ying.huang@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Yang Shi <shy828301@gmail.com>, Linux MM <linux-mm@kvack.org>,
        Greg Thelen <gthelen@google.com>,
        "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
        Jagdish Gediya <jvgediya@linux.ibm.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Alistair Popple <apopple@nvidia.com>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Michal Hocko <mhocko@kernel.org>,
        Baolin Wang <baolin.wang@linux.alibaba.com>,
        Brice Goglin <brice.goglin@gmail.com>,
        Feng Tang <feng.tang@intel.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, May 2, 2022 at 8:20 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> > 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.
>

Good point.  One tier per file should work as well.  It can be even
better to have a separate tier sub-tree.