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 C9E89C433EF for ; Tue, 10 May 2022 04:32:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48E306B0072; Tue, 10 May 2022 00:32:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 43E776B0073; Tue, 10 May 2022 00:32:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DE6E6B0074; Tue, 10 May 2022 00:32:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1DE2E6B0072 for ; Tue, 10 May 2022 00:32:23 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DF4E3305D5 for ; Tue, 10 May 2022 04:32:22 +0000 (UTC) X-FDA: 79448561724.21.CBC9893 Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by imf29.hostedemail.com (Postfix) with ESMTP id EA83F1200AD for ; Tue, 10 May 2022 04:32:15 +0000 (UTC) Received: by mail-ua1-f46.google.com with SMTP id z15so6206071uad.7 for ; Mon, 09 May 2022 21:32:22 -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=+Wbz24k8xjmUuPLei/zNpZK/WIYdnk4llOYq685eLRM=; b=mDcPIbNuXIE/Aw2IWNYjGS7CWMKV0V9DdkVv1Z1/BFInvc7e3cabhTTCMRHlVVYDJZ cOsJxOGaAuBSMIF1Iv2dLL5gm8PRTUzihr6m5RhpaRr3+jfgaS5PeN392GfwVFpJmlE2 wqPNo0ugnwx5jL8LvzPat3rJlRAFcu7D7S4mYlXKk96tKy6jr+VzrxEDnl0/n+HQ0DQZ RQSFTG+t5tOAwlHduWOXZSJojiZXx9thViC30HpODEGL4n+K/0p+GQeOmMHYKHu9hGAw F+ryed9WgCX8HL275PrtaKxA87B/lt9FldnyMCjYSm4FzBcThnpp9Z+w9D5lKhOb4/Z3 XTOA== 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=+Wbz24k8xjmUuPLei/zNpZK/WIYdnk4llOYq685eLRM=; b=tiANxRRTyfZTLBrM21D2d/3Ls5EGPZ8y16seQhfIW2sAtovQ6V926YOvaOrjP/rSBQ dn9aj4CJrhZ8VNOP+x423TcqStHMbEJWWYpvjdK2Hlqbg3+yQ/OeK4rG2JtphMUnmN7m sT5ne8ftdjMWYNuk++1FTzYO3KGyTXkBVvq1EhEcw56LECuXBnh6rMBNi/MdTIsXS/3u vyORXff6im5JgZ3c8rFhCPldij6uT7nvFvCxFtrIHILHVuWUNh2+3uCszGvoJqI9Hiof JruIlDFQdAgsKSagkLD0Zzat+mKbZP0sq+U+hAQFceq2HBDtUsH0DzvsqFV3jd5hOxn7 nRMQ== X-Gm-Message-State: AOAM532OfpQ0MYSW8h9ez/o26jQfq+bJQzbXYBau9iExkoFMQQe2OzGz 7KyfeEn5XBjUXC5nL0rvJc7fBfjPXnXxgqx76DbNHQ== X-Google-Smtp-Source: ABdhPJzmAbcvtr7lvEBP2nq942xQKZnM9LB74EU0RWqE9iN+VKrVLJmSJEkkdmrV8hpcWwDxVKgXa5pXtn9yyRA+FcU= X-Received: by 2002:ab0:7643:0:b0:362:833d:5bfb with SMTP id s3-20020ab07643000000b00362833d5bfbmr11063151uaq.4.1652157141544; Mon, 09 May 2022 21:32:21 -0700 (PDT) MIME-Version: 1.0 References: <87tua3h5r1.fsf@nvdebian.thelocal> In-Reply-To: <87tua3h5r1.fsf@nvdebian.thelocal> From: Wei Xu Date: Mon, 9 May 2022 21:32:10 -0700 Message-ID: Subject: Re: RFC: Memory Tiering Kernel Interfaces To: Alistair Popple Cc: Yang Shi , Andrew Morton , Dave Hansen , Huang Ying , Dan Williams , Linux MM , Greg Thelen , "Aneesh Kumar K.V" , Jagdish Gediya , Linux Kernel Mailing List , Davidlohr Bueso , Michal Hocko , Baolin Wang , Brice Goglin , Feng Tang , Jonathan Cameron , Tim Chen Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EA83F1200AD X-Stat-Signature: 3t3uxfhrbir35jsw5jrworkm15mzjh65 X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mDcPIbNu; spf=pass (imf29.hostedemail.com: domain of weixugc@google.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1652157135-932291 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 Thu, May 5, 2022 at 5:19 PM Alistair Popple wrote: > > Wei Xu writes: > > [...] > > >> > > >> > > >> > Tiering Hierarchy Initialization > >> > `==============================' > >> > > >> > By default, all memory nodes are in the top tier (N_TOPTIER_MEMORY). > >> > > >> > A device driver can remove its memory nodes from the top tier, e.g. > >> > a dax driver can remove PMEM nodes from the top tier. > >> > >> With the topology built by firmware we should not need this. > > I agree that in an ideal world the hierarchy should be built by firmware based > on something like the HMAT. But I also think being able to override this will be > useful in getting there. Therefore a way of overriding the generated hierarchy > would be good, either via sysfs or kernel boot parameter if we don't want to > commit to a particular user interface now. > > However I'm less sure letting device-drivers override this is a good idea. How > for example would a GPU driver make sure it's node is in the top tier? By moving > every node that the driver does not know about out of N_TOPTIER_MEMORY? That > could get messy if say there were two drivers both of which wanted their node to > be in the top tier. The suggestion is to allow a device driver to opt out its memory devices from the top-tier, not the other way around. I agree that the kernel should still be responsible for the final node-tier assignment by taking into account all factors: the firmware tables, device driver requests, and user-overrides (kernel argument or sysfs). > > I agree. But before we have such a firmware, the kernel needs to do > > its best to initialize memory tiers. > > > > Given that we know PMEM is slower than DRAM, but a dax device might > > not be PMEM, a better place to set the tier for PMEM nodes can be the > > ACPI code, e.g. acpi_numa_memory_affinity_init() where we can examine > > the ACPI_SRAT_MEM_NON_VOLATILE bit. > > > >> > > >> > The kernel builds the memory tiering hierarchy and per-node demotion > >> > order tier-by-tier starting from N_TOPTIER_MEMORY. For a node N, the > >> > best distance nodes in the next lower tier are assigned to > >> > node_demotion[N].preferred and all the nodes in the next lower tier > >> > are assigned to node_demotion[N].allowed. > >> > >> I'm not sure whether it should be allowed to demote to multiple lower > >> tiers. But it is totally fine to *NOT* allow it at the moment. Once we > >> figure out a good way to define demotion targets, it could be extended > >> to support this easily. > > > > You mean to only support MAX_TIERS=2 for now. I am fine with that. > > There can be systems with 3 tiers, e.g. GPU -> DRAM -> PMEM, but it is > > not clear yet whether we want to enable transparent memory tiering to > > all the 3 tiers on such systems. > > At some point I think we will need to deal with 3 tiers but I'd be ok with > limiting it to 2 for now if it makes things simpler. > > - Alistair > > >> > > >> > node_demotion[N].preferred can be empty if no preferred demotion node > >> > is available for node N. > >> > > >> > If the userspace overrides the tiers via the memory_tiers sysfs > >> > interface, the kernel then only rebuilds the per-node demotion order > >> > accordingly. > >> > > >> > 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. > >> > > >> > > >> > Memory Allocation for Demotion > >> > `============================' > >> > > >> > When allocating a new demotion target page, both a preferred node > >> > and the allowed nodemask are provided to the allocation function. > >> > The default kernel allocation fallback order is used to allocate the > >> > page from the specified node and nodemask. > >> > > >> > The memopolicy of cpuset, vma and owner task of the source page can > >> > be set to refine the demotion nodemask, e.g. to prevent demotion or > >> > select a particular allowed node as the demotion target. > >> > > >> > > >> > Examples > >> > `======' > >> > > >> > * Example 1: > >> > Node 0 & 1 are DRAM nodes, node 2 & 3 are PMEM nodes. > >> > > >> > Node 0 has node 2 as the preferred demotion target and can also > >> > fallback demotion to node 3. > >> > > >> > Node 1 has node 3 as the preferred demotion target and can also > >> > fallback demotion to node 2. > >> > > >> > Set mempolicy to prevent cross-socket demotion and memory access, > >> > e.g. cpuset.mems=0,2 > >> > > >> > node distances: > >> > node 0 1 2 3 > >> > 0 10 20 30 40 > >> > 1 20 10 40 30 > >> > 2 30 40 10 40 > >> > 3 40 30 40 10 > >> > > >> > /sys/devices/system/node/memory_tiers > >> > 0-1 > >> > 2-3 > >> > > >> > N_TOPTIER_MEMORY: 0-1 > >> > > >> > node_demotion[]: > >> > 0: [2], [2-3] > >> > 1: [3], [2-3] > >> > 2: [], [] > >> > 3: [], [] > >> > > >> > * Example 2: > >> > Node 0 & 1 are DRAM nodes. > >> > Node 2 is a PMEM node and closer to node 0. > >> > > >> > Node 0 has node 2 as the preferred and only demotion target. > >> > > >> > Node 1 has no preferred demotion target, but can still demote > >> > to node 2. > >> > > >> > Set mempolicy to prevent cross-socket demotion and memory access, > >> > e.g. cpuset.mems=0,2 > >> > > >> > node distances: > >> > node 0 1 2 > >> > 0 10 20 30 > >> > 1 20 10 40 > >> > 2 30 40 10 > >> > > >> > /sys/devices/system/node/memory_tiers > >> > 0-1 > >> > 2 > >> > > >> > N_TOPTIER_MEMORY: 0-1 > >> > > >> > node_demotion[]: > >> > 0: [2], [2] > >> > 1: [], [2] > >> > 2: [], [] > >> > > >> > > >> > * Example 3: > >> > Node 0 & 1 are DRAM nodes. > >> > Node 2 is a PMEM node and has the same distance to node 0 & 1. > >> > > >> > Node 0 has node 2 as the preferred and only demotion target. > >> > > >> > Node 1 has node 2 as the preferred and only demotion target. > >> > > >> > node distances: > >> > node 0 1 2 > >> > 0 10 20 30 > >> > 1 20 10 30 > >> > 2 30 30 10 > >> > > >> > /sys/devices/system/node/memory_tiers > >> > 0-1 > >> > 2 > >> > > >> > N_TOPTIER_MEMORY: 0-1 > >> > > >> > node_demotion[]: > >> > 0: [2], [2] > >> > 1: [2], [2] > >> > 2: [], [] > >> > > >> > > >> > * Example 4: > >> > Node 0 & 1 are DRAM nodes, Node 2 is a memory-only DRAM node. > >> > > >> > All nodes are top-tier. > >> > > >> > node distances: > >> > node 0 1 2 > >> > 0 10 20 30 > >> > 1 20 10 30 > >> > 2 30 30 10 > >> > > >> > /sys/devices/system/node/memory_tiers > >> > 0-2 > >> > > >> > N_TOPTIER_MEMORY: 0-2 > >> > > >> > node_demotion[]: > >> > 0: [], [] > >> > 1: [], [] > >> > 2: [], [] > >> > > >> > > >> > * Example 5: > >> > Node 0 is a DRAM node with CPU. > >> > Node 1 is a HBM node. > >> > Node 2 is a PMEM node. > >> > > >> > With userspace override, node 1 is the top tier and has node 0 as > >> > the preferred and only demotion target. > >> > > >> > Node 0 is in the second tier, tier 1, and has node 2 as the > >> > preferred and only demotion target. > >> > > >> > Node 2 is in the lowest tier, tier 2, and has no demotion targets. > >> > > >> > node distances: > >> > node 0 1 2 > >> > 0 10 21 30 > >> > 1 21 10 40 > >> > 2 30 40 10 > >> > > >> > /sys/devices/system/node/memory_tiers (userspace override) > >> > 1 > >> > 0 > >> > 2 > >> > > >> > N_TOPTIER_MEMORY: 1 > >> > > >> > node_demotion[]: > >> > 0: [2], [2] > >> > 1: [0], [0] > >> > 2: [], [] > >> > > >> > -- Wei