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 594C6C433F5 for ; Tue, 3 May 2022 07:19:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7ABCE6B0071; Tue, 3 May 2022 03:19:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75BB36B0073; Tue, 3 May 2022 03:19:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64BCE6B0074; Tue, 3 May 2022 03:19:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 517796B0071 for ; Tue, 3 May 2022 03:19:16 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1E1CA2547 for ; Tue, 3 May 2022 07:19:16 +0000 (UTC) X-FDA: 79423580712.06.EB5EB4C Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by imf04.hostedemail.com (Postfix) with ESMTP id 11A0C40089 for ; Tue, 3 May 2022 07:19:08 +0000 (UTC) Received: by mail-ua1-f45.google.com with SMTP id q4so3650037uas.0 for ; Tue, 03 May 2022 00:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4NDjuQ75ayo0y02VvOvQTGtjArT2BL7D/bx+PGGT5og=; b=BAEtmxzOwz8J5Up8A7N9UjC8/PEWOjYhRZxZhABtmKjxQIM7YjG963YwAqUMWwEYJi 4Ip6kb5BTStei89FlRkKpH4+xzSBuO2i3AvS6iR+t5srxfldrknGIZ4NQJNBvm5DIk/P 2kP/RoSqIS86DXQbBG90pNJ61ay9msF0mTf0Mi1vEuiyB5cFf4AeGx66kz3gaRXKRLob dZbgvurwSJo569DlzQmsJoQgCUojS0IWFtjm2XIjNIi6b2H+eOCURe1UjVGtXvaxECQr mKYA56F+lfX4Msi8OjHvb9wD8BVRq+TWPwbgLWKGESOCWIHi8AFI47HGl2oO81jHNqSK 9PfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4NDjuQ75ayo0y02VvOvQTGtjArT2BL7D/bx+PGGT5og=; b=Z7ADWuJPoAGFSHP1S9lkZGZ9T+6/cpNgVermjFjRDmHUupNDd8Nq4pwWeTf5E9Lq6K fj4hXMRo7FOHOXF7IoSaM4d8wOxo//h8qd/yC4fqBoF91kYnLqiqcmGyw+sS6O/zwcGO pNS7RLKiLC9Ed54Ecfl9SqccNt4YhyV2BH68r1j7Cs+j4q8LA2epxGn1JJbHGLY71Mkv +bRNmTBxzHxDnejGW2MXdRsmSEEpUZJnyW1e6aY09J/odC6QQA+KsjZ2G9fYP79LA3Mq 9CdMSm6L+eW0S91TIj+UR6Fj2DMIBWIgAbrcteVuwI7n3kvqgFgr+jOgCxpH4YIhRlLk uH+A== X-Gm-Message-State: AOAM5300gBwaAFideFr1fZD6eyjLSOyjoARfpju6u+QWV9r+glWvfQGe pP7exiD1AJgi1bDxocPNEdXJ3sJtAhbY3ST5yW57cw== X-Google-Smtp-Source: ABdhPJwav71/tsV6N6y5R9/irAJ+th9eFU4wcvvMvfs7CEykh6R5/wDjP1I4Fg+aKRpI/oPJ3c3k6C4QpqHPDZ1sBEo= X-Received: by 2002:ab0:e14:0:b0:360:e13:e5d7 with SMTP id g20-20020ab00e14000000b003600e13e5d7mr4320904uak.95.1651562352788; Tue, 03 May 2022 00:19:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wei Xu Date: Tue, 3 May 2022 00:19:01 -0700 Message-ID: Subject: Re: RFC: Memory Tiering Kernel Interfaces To: Dave Hansen Cc: Andrew Morton , Dave Hansen , Huang Ying , Dan Williams , Yang Shi , Linux MM , Greg Thelen , "Aneesh Kumar K.V" , Jagdish Gediya , Linux Kernel Mailing List , Alistair Popple , Davidlohr Bueso , Michal Hocko , Baolin Wang , Brice Goglin , Feng Tang , Jonathan Cameron Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 11A0C40089 X-Stat-Signature: gfcxs5ugs99s1kcnhjyznnms1qi43bcn Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BAEtmxzO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of weixugc@google.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=weixugc@google.com X-Rspam-User: X-HE-Tag: 1651562348-790226 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 Mon, May 2, 2022 at 8:20 AM Dave Hansen 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.