Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp1883622rdf; Sun, 5 Nov 2023 19:23:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IEUWdG15kmi7tv7hpBkoID9M/5Fu2yX+6aFMacIUHub+7cBBTCO83Eql+1cwZnRxuHFuyyK X-Received: by 2002:a05:6870:e90:b0:1ea:3e52:b66e with SMTP id mm16-20020a0568700e9000b001ea3e52b66emr37975228oab.41.1699241002700; Sun, 05 Nov 2023 19:23:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699241002; cv=none; d=google.com; s=arc-20160816; b=V8WVX62KIMBSfVhGve15A38ELvldeK1eRzdvoCb+CfWWu1SsWy8QczFMigek95KHDf bSIBEUwpTGtwJ6/3KNilNXb3f6ebA1n3qNmeGUAPVK3iryboM4MHlJzXzXY077WJVj1K Wy4fu6iP+JbK7jW6npQbBr04yWGtCqYDhz825qtHx1PIN6ya9CynFREdWFWp5v993AsA 72D6P1vzeEqUJ+FMRx+pKZDDDb54YBAH3oPxSfcX53BLrCaxbRWcC5sdbMfYYJMhJatS ffse/3Zy5E9yR5JE+g9z1y7LSUU7s+kcG97KCMspC+uptFI+wQyttV6k6+bUrFtpk1we Kmhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=41Rd5twJNSO7+4HczT/S9PkhLRlrmYDb76NUsyiih9w=; fh=si1rQhDNOeCRycOva13+aAzOhYrSidBGfHbw9OdwPK4=; b=sJCfXZGXA9ChBlpoiRztnbCtXcRKUjJ26YNdHCIi+6d/KK1ZOLburCdcQ8cuotsAFg Msv6QJaSch6rs6taMVzBYCg+5xhJAlRXOoqe2gMq8eFLpRAIyXcqWE27RZqzGga7QezS L91WCw1A/HNifVPOegOaNfPdGKwOb458RU4I8fjyNN7a1Ob8DMtS2w8WlJMyxaRKpEKw xMwnK5tPj69gpkYCHeyZJ23FeVap1J2ys3tzOa0TAmtHlrnC8z3BYcqRt8LAZYzSpmAg 1BxG1r+pTBKUjmnUdgelZONuhj1FEMOrVR8/IV05eomCpsC9fwEk9l9AHII/ZvY2LsS6 4HBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Ih1RGuf/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id l26-20020a63ba5a000000b00578a28df3e2si7401940pgu.816.2023.11.05.19.23.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Nov 2023 19:23:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Ih1RGuf/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 1A43B80A0DD6; Sun, 5 Nov 2023 19:23:20 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230147AbjKFDXI (ORCPT + 99 others); Sun, 5 Nov 2023 22:23:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229485AbjKFDXH (ORCPT ); Sun, 5 Nov 2023 22:23:07 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5500BB; Sun, 5 Nov 2023 19:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699240985; x=1730776985; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=d0GJaRr0bVj8J9IvowV4cvGbvN8Uw+bGKm4vNcfReLQ=; b=Ih1RGuf/Dl6IHo46U6SnpoxFL/W360YLXJgRzy8qoksdqggrGr6e08Kf eJtMiOml+ZJQsbLFsRsj4up5D89Vqu9e8w9ZLrCn8nSRsKdicYn1IE9HB NbMV8G/NBdvzaWWEl5BaG4AuvGqzQCrHcSlt+i+dDHnuh9ikidjmP7fee 8Lujh1LaF3nwYQJrxSoEWq1mwLXnvehJxNCoefh+SLQNlWTHy7GW9lfwW tZ60zfWi8PYeoYKTLW0FJtNvS6oyifov9teR/2Mg5X4xcbG6DIv2D7OWw 4Nxx4lgb0sC/IG3nwB6Txd9MRTlUIUOHDRmLKOXOaOXpUpPgLdvrDWfKs A==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="2182573" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="2182573" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 19:23:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="885772160" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="885772160" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 19:23:00 -0800 From: "Huang, Ying" To: Jonathan Cameron Cc: Gregory Price , Michal Hocko , Johannes Weiner , Gregory Price , , , , , , , , , , , , Subject: Re: [RFC PATCH v3 0/4] Node Weights and Weighted Interleave In-Reply-To: <20231103141636.000007e4@Huawei.com> (Jonathan Cameron's message of "Fri, 3 Nov 2023 14:16:36 +0000") References: <20231031003810.4532-1-gregory.price@memverge.com> <20231031152142.GA3029315@cmpxchg.org> <87fs1nz3ee.fsf@yhuang6-desk2.ccr.corp.intel.com> <20231103141636.000007e4@Huawei.com> Date: Mon, 06 Nov 2023 11:20:58 +0800 Message-ID: <8734xjworp.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 05 Nov 2023 19:23:20 -0800 (PST) Jonathan Cameron writes: > On Fri, 03 Nov 2023 15:45:13 +0800 > "Huang, Ying" wrote: > >> Gregory Price writes: >> >> > On Thu, Nov 02, 2023 at 10:47:33AM +0100, Michal Hocko wrote: >> >> On Wed 01-11-23 12:58:55, Gregory Price wrote: >> >> > Basically consider: `numactl --interleave=all ...` >> >> > >> >> > If `--weights=...`: when a node hotplug event occurs, there is no >> >> > recourse for adding a weight for the new node (it will default to 1). >> >> >> >> Correct and this is what I was asking about in an earlier email. How >> >> much do we really need to consider this setup. Is this something nice to >> >> have or does the nature of the technology requires to be fully dynamic >> >> and expect new nodes coming up at any moment? >> >> >> > >> > Dynamic Capacity is expected to cause a numa node to change size (in >> > number of memory blocks) rather than cause numa nodes to come and go, so >> > maybe handling the full node hotplug is a bit of an overreach. >> >> Will node max bandwidth change with the number of memory blocks? > > Typically no as even a single memory extent would probably be interleaved > across all the actual memory devices (think DIMMS for simplicity) within > a CXL device. I guess a device 'could' do some scaling based on capacity > provided to a particular host but feels like they should be separate controls. > I don't recall there being anything in the specification to suggest the > need to recheck the CDAT info for updates when DC add / remove events happen. Sounds good! Thank you for detailed explanation. > Mind you, who knows in future :) We'll point out in relevant forums that > doing so would be very hard to handle cleanly in Linux. Thanks! -- Best Regards, Huang, Ying