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 2D2C1C43334 for ; Wed, 8 Jun 2022 18:15:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5BD46B0071; Wed, 8 Jun 2022 14:15:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0CB86B0072; Wed, 8 Jun 2022 14:15:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F95E6B0073; Wed, 8 Jun 2022 14:15:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 918416B0071 for ; Wed, 8 Jun 2022 14:15:32 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4FE2A21552 for ; Wed, 8 Jun 2022 18:15:32 +0000 (UTC) X-FDA: 79555871304.01.E4FCB12 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf19.hostedemail.com (Postfix) with ESMTP id 6DD9D1A0012 for ; Wed, 8 Jun 2022 18:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654712131; x=1686248131; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=vpePlkkr31O+12oQPMGrUPgWXPUGbY6W3sgTE/Dq26M=; b=JXSlqPI9QF6sTWNpD30kF/Z0rwB0TgzMT+Ph3yN0F82cGaGoHzwJhpvH GBNILIDA9bFhfzZhTHmDde/7bqF2mcM6XNrInUpbCSXdSmEgRGl414R7e qJ/CFo8ena5NvbNky2dW+4wJwjG2HqNkgSKa1iPg3v9GHO6Bq9bwcuoo0 uw/TP+aKocdlaq8OlE5vSp5hyFXxcSnVRuvVwylrOW6+lkghh8wcQY3zK YokrjNebQNZG1YwgH90VYfS6X345FRccCzhYoGEvI4I0XUKFSINz6dIa2 tsqcyeoVgxn3Y2oYynz+YMLE4JYIhiw728MhkC5yW5WJi+v2SjAlELtqV g==; X-IronPort-AV: E=McAfee;i="6400,9594,10372"; a="341092992" X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208";a="341092992" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 11:15:28 -0700 X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208";a="580180635" Received: from schen9-mobl.amr.corp.intel.com ([10.209.124.119]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 11:15:27 -0700 Message-ID: <6096c96086187e51706898e58610fc0148b4ca23.camel@linux.intel.com> Subject: Re: [PATCH] mm: mempolicy: N:M interleave policy for tiered memory nodes From: Tim Chen To: Johannes Weiner , linux-mm@kvack.org Cc: Hao Wang , Abhishek Dhanotia , "Huang, Ying" , Dave Hansen , Yang Shi , Davidlohr Bueso , Adam Manzanares , linux-kernel@vger.kernel.org, kernel-team@fb.com, Hasan Al Maruf Date: Wed, 08 Jun 2022 11:15:27 -0700 In-Reply-To: <20220607171949.85796-1-hannes@cmpxchg.org> References: <20220607171949.85796-1-hannes@cmpxchg.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6DD9D1A0012 X-Stat-Signature: 37kuajbq6reag5kwwz6budjrgtbyeyc1 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=JXSlqPI9; spf=none (imf19.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=tim.c.chen@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1654712131-733415 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 Tue, 2022-06-07 at 13:19 -0400, Johannes Weiner wrote: > > /* Do dynamic interleaving for a process */ > static unsigned interleave_nodes(struct mempolicy *policy) > { > unsigned next; > struct task_struct *me = current; > > - next = next_node_in(me->il_prev, policy->nodes); > + if (numa_tier_interleave[0] > 1 || numa_tier_interleave[1] > 1) { When we have three memory tiers, do we expect an N:M:K policy? Like interleaving between DDR5, DDR4 and PMEM memory. Or we expect an N:M policy still by interleaving between two specific tiers? The other question is whether we will need multiple interleave policies depending on cgroup? One policy could be interleave between tier1, tier2, tier3. Another could be interleave between tier1 and tier2. In the current implementation we have one global interleave knob defined by numa_iter_interleave[]. Tim