From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 470CA34575D for ; Thu, 9 Apr 2026 14:10:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775743858; cv=none; b=eEdwVLszELTiitteLvzqP6GlcNFkWQzwNk7PsNARuoSVKAcIVd5suRdEsrqRGRfjbcLIXBksKCBi00PIKkWZdUGK+jgculnAvwyTBToEOLwiCiPPQRZZs5CKhhMVkV64jwgIvXcrvRqtb4gDI9SKZWcQNHMtd9xa31czv7mwuUI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775743858; c=relaxed/simple; bh=Sr0aa5047BULnoz+tz6bZPxDgIbzh+0PjLY+QuVemfw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bAxkv7kEdGXayjXGr4khfnO3Qib9KUbpLUFGt0BarCpCKezmjr8tad5xtqFeQ+x7dmz775PuTEQARX+L11APs4AE5nx9MTZRXMXfOedX5KJXn384LYX8P86TOeefOiwkZLWSyhSicVlGc3ku7ypud0oaJCwE8WiyEHr9JwOAdE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=tMZNIqxN; arc=none smtp.client-ip=209.85.222.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="tMZNIqxN" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-8d4ba1518afso73970085a.0 for ; Thu, 09 Apr 2026 07:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1775743855; x=1776348655; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2DKBJ+IO8Lwrv7Ar+fdmkyOV0YR2H4q+x5+ZupyiskY=; b=tMZNIqxNsm7K0ybaJMvqVBslzwDApnzjoIbrhKX+Ven4aom4MY+wL763RlGTKI0mYa B8TPt+DMp2T0Q2fLSnhqe+mFNhNHrdMtHxvcxLoH3Ne9ze/T+wRTrCJTDdqMcU1R6few p+TmvkHOsRxd93nVoqx1FYOQg9p76E2RLASjkJlkSCqhhF6jBfqXUqwxh4JTMaD5U5In 0xVVumzanckSKyRWUMmsPqjnIObcytJ2XscBvGLxMQSUZt+FYaMqtYYAml4GzWexo8hp gIwppU6bWu0bMLQuVBnxXVOvEvD8sjxO8eDk/eseAz2n2tjFpnhrC+HZoCCUhbud+BfG n8zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775743855; x=1776348655; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2DKBJ+IO8Lwrv7Ar+fdmkyOV0YR2H4q+x5+ZupyiskY=; b=HIye24lEV5Kwp70LHVVTPXO/bmy9SDK9yqDL7sAACod5I17UZa+tcpkYSyNIJbxxrB NSeSuHDpU1lIdysHLU/RHSlBKwof9NujcF47Lc5yRAqprG4mDox4TGvs/Capbm0nC0Lm MuqPsDYtO6qt4HZCIU8mdaMSWtH+7/gdtZg7xF7/wpTS+m5zog6HH9VfmJKs17rGEBGk 7LpQhsW2h2lQoD2Xxy3I4EXL1ccA9RvhiabqUr/PoqnlL2e/VYw3VPa97BdrfMAEHhvA aPH3ZUrrwKgyJkHbUZyOwHViIg+20kHUtnU1WL1gvRv3i1QGnJ27Z+SRQr8RQOSbr23F tYtQ== X-Forwarded-Encrypted: i=1; AJvYcCUqvWzAM9tcRhpTI5N/fLthLqz8ZPA1dfn9KcNZJC7mjpZzE1D7H7BaRPzEAct6aRUexZeCw80cBhucUl8=@vger.kernel.org X-Gm-Message-State: AOJu0YyI/gKDSfMzih99ih6Q6OMKZdtIfSboqpIvnRdWQ3Ef6WDbiVKK NPsLLdubQkK3Ci9rVWDdIwMhN5pDSlRWwIfbjDMho98QqkmQmmdO6VlgBK6rFiAFJSc= X-Gm-Gg: AeBDieu4Owzuq0fFQD7Wy79W7L73rx/BYkE5g6aoDx9VYqNESCyOOK0AigZPgPbXQp0 md8DH4EtI+e7fAP1EegrzaBeXknjGQekouV//bJFnVBcHcvUb+t8SifJdDwwFg+pA5Sta73t6ST jzDk2CiV9+uS5HBaTGlDDhpEL74fUVqvJj69+jDKw72b73PRPCIripzcFi53yYTm9hkxyHBg7m7 AZU7NMkWZw+1iXtZmDDllzkaN9YbQVEQ7S2SCbjpIfxLYKqgzJuZFM7OuYs0kpE47pEiscg7uTU J9bLzIaAq5zHyvI9euB6ET6VZvaQmJpz1YoGSWyLRPvzWdqm2jw+tdkvafPVRYP+cU1+043WU8D zQQpHyvQu7vpa9feZTRMK+2nAOfHiPEWG3I32AM6u3FLfHLz2QhNJgEvt084Pog38GxLpvatGZF rNVjZ6AA/MR0J98ZVZxg/hCdB2I0UaGXUizhjZdW7om/v/cExJgnMsfm+hbzbZW0GXcbLnDmuFD L+tc4A9F41g X-Received: by 2002:a05:620a:4892:b0:8d1:b71e:10a0 with SMTP id af79cd13be357-8dc440c9f39mr456066185a.5.1775743854719; Thu, 09 Apr 2026 07:10:54 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-71-191-243-150.washdc.fios.verizon.net. [71.191.243.150]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8db0d85a237sm391985285a.5.2026.04.09.07.10.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 07:10:54 -0700 (PDT) Date: Thu, 9 Apr 2026 10:10:52 -0400 From: Gregory Price To: Ritesh Harjani Cc: "Huang, Ying" , Donet Tom , David Hildenbrand , Andrew Morton , Ingo Molnar , Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Baolin Wang , Ying Huang , Juri Lelli , Mel Gorman Subject: Re: [PATCH v2] memory tiering: Do not allow promotion if NUMA_BALANCING_MEMORY_TIERING is disabled Message-ID: References: <20260323094849.3903-1-donettom@linux.ibm.com> <87wlyqt52m.fsf@DESKTOP-5N7EMDA> <87o6k1ubg4.fsf@DESKTOP-5N7EMDA> <877bqgvs4k.fsf@DESKTOP-5N7EMDA> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Apr 09, 2026 at 09:12:56AM +0530, Ritesh Harjani wrote: > "Huang, Ying" writes: > > >>>>> Donet Tom writes: > >> > >> > >> Thanks for the clarification. I was running some experiments where I > >> only required migration, not promotion. However, I observed that > >> promotion was still occurring even when NUMA_BALANCING_MEMORY_TIERING > >> was disabled, which led me to believe it might be a bug, so I reported > >> it. > >> > >> As I understand it, enabling both NUMA_BALANCING_MEMORY_TIERING and > >> NUMA_BALANCING_NORMAL results in both promotion and migration. Given > >> this, do you see any concerns with modifying the behavior of > >> NUMA_BALANCING_NORMAL? > >> > >> With this patch, we would have better control over enabling and > >> disabling promotion independently. I would appreciate your thoughts on > >> this. > > > > IIUC, we change the existing user visible behavior only with strong > > enough practical reason. > > So what I understood from this discussion so far is, we don't have any > mechanism to do auto-numa base page migration between DRAM -to- DRAM w/o > triggering promotions too from a lower tiers to higher tiers. > > ... This to me sounds more like a broken interface. > It only seems that way because the naming suggests tiering did not exist prior to _TIERING - instead _NORMAL just operates in a suboptimal manner when multiple tiers exist. _NORMAL migrates a page when it detects the node it's on is not the local node of the task doing the work. _TIERING takes into account the liveliness of the pages with a timestamp. Going to agree with Ying here - this change should be dropped without additional data. If you can show _NORMAL would be better off not moving low-tier pages for at least a handful of common benchmarks, or that _NORMAL is causes incorrect placement - then I think this change is warranted. But as it is, this would just be a behavioral change without supporting data to justify it. ~Gregory