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 X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79391C433E0 for ; Tue, 30 Jun 2020 19:26:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B6CF206C0 for ; Tue, 30 Jun 2020 19:26:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="d+8whJ+C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B6CF206C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 920B96B0002; Tue, 30 Jun 2020 15:26:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D19B6B0003; Tue, 30 Jun 2020 15:26:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C3EA6B0006; Tue, 30 Jun 2020 15:26:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id 63DE56B0002 for ; Tue, 30 Jun 2020 15:26:12 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0D1BD2DFA for ; Tue, 30 Jun 2020 19:26:12 +0000 (UTC) X-FDA: 76986858984.11.swing39_410d45f26e7a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id E1F77180F8B81 for ; Tue, 30 Jun 2020 19:26:11 +0000 (UTC) X-HE-Tag: swing39_410d45f26e7a X-Filterd-Recvd-Size: 4995 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Tue, 30 Jun 2020 19:26:11 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id t74so12085653lff.2 for ; Tue, 30 Jun 2020 12:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zp5IF5vcvuCu2gwgY+TzliRbsIBW1Igf4k0wqLGBZVA=; b=d+8whJ+CDvQp9gSztOTjyISsxB6w/oE1k0dTkyIrGpYzlrO1923v7B0bIv+IZMVGtc dHtFpgYgpYYUSlaPoDeUP9I94LkopNHp2EZ+iFMcvnZA4TB+3hgToQ7S6eDAA1muI9o/ 5UKWmPsC+oibSBac8iv2DnroNKr+dyZkRFHQoQobMflsbEJEscezjSQAYg7aCCfsIWmo 8ykwdNfJY0VYnbwzdHOOUJYRpzDOPDGitc8zLOW5XmPuGnMxgwRcq2xbU59NbAfZY16z 8ffEaE3N2dArYpSp4EMqD4MWE80Fiqpts6cMXsAL+Ke2DDnJAtLKGEeg2ZHlntLKE+Q/ K0nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zp5IF5vcvuCu2gwgY+TzliRbsIBW1Igf4k0wqLGBZVA=; b=eb6jREOnINnpI+8z7dh/NulMenIkaK1Mh3D+pnvOz0GnOq7x+78cb6+Wl5C3GztJ3u Wbz9DBlHFsFe67FVkIIT1OzUo4F63Egu6v1hGrlNYFZDPQksEdigwP0aNUYQwwFZvV/g KDcPCW/iMatPvxgMIrw3nW9ZgxWtjCYgTe74xTycaekk9fyVg2O7BfoB5QaU+efiT/tE izdkAUn9xeqft9B7/Ug92lHc7EI437Gu5WySLygmWNE6T8Mx0exyurySaCmmzUqfeapE es9mu4HtcnqOL9+LeEYOfcwpFC1RrkzWRjRThSqruR53EalRg9aA7HJmHi/Nx7t8gRwR 8a4Q== X-Gm-Message-State: AOAM5338iR8l0FVoTV+maI2p6QVoAYWL6MXgl+EA9baLDi1vfsacL0KA Q4xEC3xtfLQtKGaq+VTCS8G/twNdlri/lvdxR94fdw== X-Google-Smtp-Source: ABdhPJw6Oa8Vk19NEDCPKZSad/tRxr0zgylemKX4mDPL8U6NR6qoINtpwhEq2uZrbweXXWRp9WjWNi5OPRzeVRhOvsk= X-Received: by 2002:a05:6512:482:: with SMTP id v2mr12596062lfq.3.1593545167726; Tue, 30 Jun 2020 12:26:07 -0700 (PDT) MIME-Version: 1.0 References: <20200629234503.749E5340@viggo.jf.intel.com> <654d785f-3fe5-d8bd-86bf-bf7431527184@intel.com> In-Reply-To: <654d785f-3fe5-d8bd-86bf-bf7431527184@intel.com> From: Shakeel Butt Date: Tue, 30 Jun 2020 12:25:56 -0700 Message-ID: Subject: Re: [RFC][PATCH 0/8] Migrate Pages in lieu of discard To: Dave Hansen Cc: Dave Hansen , LKML , Linux MM , Yang Shi , David Rientjes , Huang Ying , Dan Williams Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E1F77180F8B81 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 30, 2020 at 11:51 AM Dave Hansen wrote: > > On 6/30/20 11:36 AM, Shakeel Butt wrote: > >> This is part of a larger patch set. If you want to apply these or > >> play with them, I'd suggest using the tree from here. It includes > >> autonuma-based hot page promotion back to DRAM: > >> > >> http://lkml.kernel.org/r/c3d6de4d-f7c3-b505-2e64-8ee5f70b2118@intel.com > >> > >> This is also all based on an upstream mechanism that allows > >> persistent memory to be onlined and used as if it were volatile: > >> > >> http://lkml.kernel.org/r/20190124231441.37A4A305@viggo.jf.intel.com > >> > > I have a high level question. Given a reclaim request for a set of > > nodes, if there is no demotion path out of that set, should the kernel > > still consider the migrations within the set of nodes? > > OK, to be specific, we're talking about a case where we've arrived at > try_to_free_pages() Yes. > and, say, all of the nodes on the system are set in > sc->nodemask? Isn't the common case that all nodes are set in > sc->nodemask? Depends on the workload but for normal users, yes. > Since there is never a demotion path out of the set of > all nodes, the common case would be that there is no demotion path out > of a reclaim node set. > > If that's true, I'd say that the kernel still needs to consider > migrations even within the set. In my opinion it should be a user defined policy but I think that discussion is orthogonal to this patch series. As I understand, this patch series aims to add the migration-within-reclaim infrastructure, IMO the policies, optimizations, heuristics can come later. BTW is this proposal only for systems having multi-tiers of memory? Can a multi-node DRAM-only system take advantage of this proposal? For example I have a system with two DRAM nodes running two jobs hardwalled to each node. For each job the other node is kind of low-tier memory. If I can describe the per-job demotion paths then these jobs can take advantage of this proposal during occasional peaks.