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 71D87C433EF for ; Fri, 13 May 2022 06:37:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E7FC8D0001; Fri, 13 May 2022 02:37:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 097AC6B0075; Fri, 13 May 2022 02:37:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA2398D0001; Fri, 13 May 2022 02:37:08 -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 DA59B6B0073 for ; Fri, 13 May 2022 02:37:08 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B7DA061387 for ; Fri, 13 May 2022 06:37:08 +0000 (UTC) X-FDA: 79459762536.09.669EF6D Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf29.hostedemail.com (Postfix) with ESMTP id 029C81200C3 for ; Fri, 13 May 2022 06:37:00 +0000 (UTC) Received: by mail-vk1-f171.google.com with SMTP id e144so3753291vke.9 for ; Thu, 12 May 2022 23:37:07 -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=OinVFhkgVxz8G6r3WLh+5ytD4Oovn7TM4M9+J0/PGsM=; b=sUHlLm+z2dE3XMIFfMyb0yhLzLwh3dENmJkGV/c3cLLymCaIEPVpL0WNlKX+OpLMZb 3nNAqXzsoFqzV9t1Lsy5rny1SiRpZiG+kNJ9yRXk2g8AceJJn7F00Vb1x3jY4TX4SSO0 zCNp0fAitWKMHWxV3xeu/z5MVwViDcAk5mSHPEj0HaI/okftzDmS7c3hx69TEZyoFp9f hIcJKPflhQUjtszBL0c2QxKVZ3FkeP017ZYdQK/PpZWwfTt4bm7J++FKeMDREp2O7KhT ypE4fmu2X2o8VElW5D8b5pIPGSQZZ5UpokHrJERtn0a9hdaiZ+fBpb+PqMqWculxWhaD u7Mg== 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=OinVFhkgVxz8G6r3WLh+5ytD4Oovn7TM4M9+J0/PGsM=; b=7vt29frbv7PDrF/irbE+YNf8gqo86n5tG0EdI2wTK5yjxmx69LmwW96WplpKptOBhB 8tJDNZt9I9PqLD/iBqi5ooKx912LydSUAInLHMjN8SPrMDIbsMrpCw/OGN90ovFxRW/i iJAFhCOB+Gq5FDzZr+bfH3bF+7HiOM84CEm5AEeZ3h+1n01y4EMeJdE6Huj+dFV7G+NJ rUpB/WgvJgXQgLDfLuJgz3oN1YqGEgLlFhnBxDZl+uSxnme8fTtHtFwYOWrcZCjvwwJm LSWjxQwWyczsq18FlSl1I367GlDy/7Qrn6aOZBRLthtJkeerwpCf1ve2i1mtEvhql9eP z70w== X-Gm-Message-State: AOAM531ueB2PVSYfn5wLG6mMTRK0LdcOb8Qmb5MXK0l8eI9sc1O2x47c wj8DMx0s+Tyrpqcxy0nQ5ysiHWQmMK5YLJeBOZMW0Q== X-Google-Smtp-Source: ABdhPJxbsPRoVd0/nr3aQ/+OAjoXsgkhute2b1VdD+5S6CsOP9/aAEoZKUA/2AVBQUoMpp5mkWqRsBUK7uuGKpsjSbo= X-Received: by 2002:a05:6122:2386:b0:352:5a79:5a43 with SMTP id bu6-20020a056122238600b003525a795a43mr1570390vkb.23.1652423827326; Thu, 12 May 2022 23:37:07 -0700 (PDT) MIME-Version: 1.0 References: <69f2d063a15f8c4afb4688af7b7890f32af55391.camel@intel.com> In-Reply-To: <69f2d063a15f8c4afb4688af7b7890f32af55391.camel@intel.com> From: Wei Xu Date: Thu, 12 May 2022 23:36:56 -0700 Message-ID: Subject: Re: RFC: Memory Tiering Kernel Interfaces (v2) To: "ying.huang@intel.com" Cc: Andrew Morton , Greg Thelen , "Aneesh Kumar K.V" , Yang Shi , Linux Kernel Mailing List , Jagdish Gediya , Michal Hocko , Tim C Chen , Dave Hansen , Alistair Popple , Baolin Wang , Feng Tang , Jonathan Cameron , Davidlohr Bueso , Dan Williams , David Rientjes , Linux MM , Brice Goglin , Hesham Almatary Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: eu6i4t5giprcpegqsfqs5tmyug46ntzq X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 029C81200C3 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sUHlLm+z; spf=pass (imf29.hostedemail.com: domain of weixugc@google.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-HE-Tag: 1652423820-411070 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 12, 2022 at 8:25 PM ying.huang@intel.com wrote: > > On Wed, 2022-05-11 at 23:22 -0700, Wei Xu wrote: > > > > Memory Allocation for Demotion > > ============================== > > > > To allocate a new page as the demotion target for a page, the kernel > > calls the allocation function (__alloc_pages_nodemask) with the > > source page node as the preferred node and the union of all lower > > tier nodes as the allowed nodemask. The actual target node selection > > then follows the allocation fallback order that the kernel has > > already defined. > > > > The pseudo code looks like: > > > > targets = NODE_MASK_NONE; > > src_nid = page_to_nid(page); > > src_tier = node_tier_map[src_nid]; > > for (i = src_tier + 1; i < MAX_MEMORY_TIERS; i++) > > nodes_or(targets, targets, memory_tiers[i]); > > new_page = __alloc_pages_nodemask(gfp, order, src_nid, targets); > > > > The memopolicy of cpuset, vma and owner task of the source page can > > be set to refine the demotion target nodemask, e.g. to prevent > > demotion or select a particular allowed node as the demotion target. > > Consider a system with 3 tiers, if we want to demote some pages from > tier 0, the desired behavior is, > > - Allocate pages from tier 1 > - If there's no enough free pages in tier 1, wakeup kswapd of tier 1 so > demote some pages from tier 1 to tier 2 > - If there's still no enough free pages in tier 1, allocate pages from > tier 2. > > In this way, tier 0 will have the hottest pages, while tier 1 will have > the coldest pages. When we are already in the allocation path for the demotion of a page from tier 0, I think we'd better not block this allocation to wait for kswapd to demote pages from tier 1 to tier 2. Instead, we should directly allocate from tier 2. Meanwhile, this demotion can wakeup kswapd to demote from tier 1 to tier 2 in the background. > With your proposed method, the demoting from tier 0 behavior is, > > - Allocate pages from tier 1 > - If there's no enough free pages in tier 1, allocate pages in tier 2 > > The kswapd of tier 1 will not be waken up until there's no enough free > pages in tier 2. In quite long time, there's no much hot/cold > differentiation between tier 1 and tier 2. This is true with the current allocation code. But I think we can make some changes for demotion allocations. For example, we can add a GFP_DEMOTE flag and update the allocation function to wake up kswapd when this flag is set and we need to fall back to another node. > This isn't hard to be fixed, just call __alloc_pages_nodemask() for each > tier one by one considering page allocation fallback order. That would have worked, except that there is an example earlier, in which it is actually preferred for some nodes to demote to their tier + 2, not tier +1. More specifically, the example is: 20 Node 0 (DRAM) -- Node 1 (DRAM) | | | | | | 30 120 | | | v v | 100 100 | Node 2 (PMEM) | | | | | | 100 | \ v v -> Node 3 (Large Mem) Node distances: node 0 1 2 3 0 10 20 30 100 1 20 10 120 100 2 30 120 10 100 3 100 100 100 10 3 memory tiers are defined: tier 0: 0-1 tier 1: 2 tier 2: 3 The demotion fallback order is: node 0: 2, 3 node 1: 3, 2 node 2: 3 node 3: empty Note that even though node 3 is in tier 2 and node 2 is in tier 1, node 1 (tier 0) still prefers node 3 as its first demotion target, not node 2.