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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BB41ACA9EAF for ; Fri, 25 Oct 2019 03:30:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8BBEC21929 for ; Fri, 25 Oct 2019 03:30:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BBEC21929 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 229716B0003; Thu, 24 Oct 2019 23:30:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D9FC6B0006; Thu, 24 Oct 2019 23:30:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F0726B0007; Thu, 24 Oct 2019 23:30:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id DBB5E6B0003 for ; Thu, 24 Oct 2019 23:30:51 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 83BEB584C for ; Fri, 25 Oct 2019 03:30:51 +0000 (UTC) X-FDA: 76080880302.29.uncle66_2471d47d5541c X-HE-Tag: uncle66_2471d47d5541c X-Filterd-Recvd-Size: 3285 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Oct 2019 03:30:50 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2019 20:30:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,227,1569308400"; d="scan'208";a="398638072" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.29]) by fmsmga005.fm.intel.com with ESMTP; 24 Oct 2019 20:30:46 -0700 From: "Huang\, Ying" To: Dave Hansen Cc: Jonathan Adams , Linux-MM , LKML , "Williams\, Dan J" , "Verma\, Vishal L" , Wu Fengguang Subject: Re: [RFC] Memory Tiering References: Date: Fri, 25 Oct 2019 11:30:46 +0800 In-Reply-To: (Dave Hansen's message of "Thu, 24 Oct 2019 09:33:01 -0700") Message-ID: <87o8y5h57d.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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: Dave Hansen writes: > On 10/23/19 4:11 PM, Jonathan Adams wrote: >> we would have a bidirectional attachment: >> >> A is marked "move cold pages to" B >> B is marked "move hot pages to" A >> C is marked "move cold pages to" D >> D is marked "move hot pages to" C >> >> By using autonuma for moving PMEM pages back to DRAM, you avoid >> needing the B->A & D->C links, at the cost of migrating the pages >> back synchronously at pagefault time (assuming my understanding of how >> autonuma works is accurate). >> >> Our approach still lets you have multiple levels of hierarchy for a >> given socket (you could imaging an "E" node with the same relation to >> "B" as "B" has to "A"), but doesn't make it easy to represent (say) an >> "E" which was equally close to all sockets (which I could imagine for >> something like remote memory on GenZ or what-have-you), since there >> wouldn't be a single back link; there would need to be something like >> your autonuma support to achieve that. >> >> Does that make sense? > > Yes, it does. We've actually tried a few other approaches separate from > autonuma-based ones for promotion. For some of those, we have a > promotion path which is separate from the demotion path. > > That said, I took a quick look to see what the autonuma behavior was and > couldn't find anything obvious. Ying, when moving a slow page due to > autonuma, do we move it close to the CPU that did the access, or do we > promote it to the DRAM close to the slow memory where it is now? Now in autonuma, the slow page will be moved to the CPU that did the access. So I think Jonathan's requirement has been covered already. Best Regards, Huang, Ying