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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26B65CCA483 for ; Wed, 8 Jun 2022 18:17:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235978AbiFHSRI (ORCPT ); Wed, 8 Jun 2022 14:17:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235234AbiFHSPa (ORCPT ); Wed, 8 Jun 2022 14:15:30 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7663CF66 for ; Wed, 8 Jun 2022 11:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654712128; x=1686248128; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=vpePlkkr31O+12oQPMGrUPgWXPUGbY6W3sgTE/Dq26M=; b=Zoh89d9hbU2p3iEu+36XAK7EqGCm16FVz/+rxiEi1KceuShJp0fE9WX4 5ENHxktXQSCfT1GSd4X7a33Tvlh++Lhi7QO2gQ0wXYTX+3bDDMbZ4/u5q O8YPv6cv+nOF3LUC9dGSsU+HigGMcv1FMwwTh9NDzk+FBuWEg90QRD92E fLpzuyISLnBjZ2Wu90eAHWrsa6qGxjmqTMB+XAFB9TgalJw74oxb1+uG7 TggKE3DR2atvDsX/IVYhedZvqXiGy/gYvcQ/fHJN5a+/PI8WvC+sXMT9G ttR9zgLrxwmaYymazbwJOp4eq4glNtumfzaW21jAyCVQxwv0bLyI1CHHY w==; X-IronPort-AV: E=McAfee;i="6400,9594,10372"; a="277822160" X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208";a="277822160" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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