From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f45.google.com (mail-yx1-f45.google.com [74.125.224.45]) (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 E226B2E40E for ; Sat, 10 Jan 2026 00:52:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768006353; cv=none; b=RZ0f9bPuqPvreyiAfNrNGwMgHMEZQXo32GRopjenH6ONU1DHk7+LE29zx+OWJVEHdyVwB0Rgol4Y5xqyO9c+m4IfdU+3esNsRqXXUobj3cpfSDMqZjdtK0OZT6ZMQziUUHKi4nW4ZpPDG3+jT7aiUPuydnlb5eOrpwQ5DB/Gr4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768006353; c=relaxed/simple; bh=NXHw0flUtEIHX4b2aV501GjBGoMpZohAQbfPwokTD6E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HNfjSAVH9q+TdI+y09TR1IXyMu2MvrN0FTVrXiTGbVRI4g6LN1kWR8Wb/5GVE1vFoqqmrqkiJFsWjgZZBwrkRROqkvZrskoJoEwGFUT//kCAvxL06Tqn1SS6IC1tlRrrV8nehfALbvVK/TT7m2VrZlewnSD5ecoZWoVYpMYrYUk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gzvCczOC; arc=none smtp.client-ip=74.125.224.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gzvCczOC" Received: by mail-yx1-f45.google.com with SMTP id 956f58d0204a3-6420c08f886so6861266d50.3 for ; Fri, 09 Jan 2026 16:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768006351; x=1768611151; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=xh0zcKAqQroU1tp1p4pimwYJeCFYqvdejY8GmA8WI20=; b=gzvCczOCOS28b5gDIxMfum581AOYe1bOBkWwgfWqv8WzO3OzdOdctHLWzCQMdYlFXt /WOD2kFUT0mawFUXtzJO4vxunbrHdBxjfajXk/j4UagWL+8sOITq7UdKlZfk/xt+1ev7 7qcoBJp/zH8OvN0Di+rZdGqA6vLYLuZ5DiUKRkRIb9APogoVSSBaJK/Hx2Rwm6KfyKQh fv0zOnlYLIz5kN5M5q+jXKb6Tk+Vwz15r5eQAfOQ7W7uB9O4v6z13ygjJ+O36iSXnzIp wurF8ZUb60r5Vqkdd1Ms+LpsRSLWCQxZ9RCcVFYDFsFELAdLZbS0FWRo4uGFouR2iBMm 6W1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768006351; x=1768611151; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xh0zcKAqQroU1tp1p4pimwYJeCFYqvdejY8GmA8WI20=; b=fzXmiQprehRLjJktqoHJohSgf2NSc5iTTAkW1mSvZ3m7N0dgiKSueBKjPR1lqT23Mf Zv6PNFw4UL5U1KblPZIIA0N/vNjOQjhtyBsgS6cfJxSqSaaZuDDIEnXIM0RqITnPsxdr ij82urwmbubL7ykH29G+xoO+IxgluPy4qxs6tPGF1OhZKDppwtyiOpSw405EdBtV1AZv rK8ghYUcQJiDmtvHoRvzhJhNehj7uOquVpR4M+aHiSXzV3Ckzc78k/mi6nUDu7nd3bHm cm5rJ4wSDTCbMlhIlIsPSGwQQMmZZia6v8ZfMbtNLC838sGYNCLKaLu2CAWDVaMpb518 bjCQ== X-Forwarded-Encrypted: i=1; AJvYcCVBt/YR6UfR+2q93yet18i0HVjJwcp3ZizmfXRmI4TrZCWYIv9e1CH2Lcben53pYuVzDDISwd3eNwPIRZY=@vger.kernel.org X-Gm-Message-State: AOJu0YzKi6ihHmiC2ZwI+8TGDfMgiAHAUl3+BU8+A+jhVU0btvR0v+Va k8S9nfcmOyNZoJR5K4ow4tYs925edhcK1WPH77d/8Wh/dej8OpfuXrve X-Gm-Gg: AY/fxX60OWbDS9Z500mVoi2gsIybHqNBRkjDJgF6efsy7/R3e2k4z6UFQ9c3QXj9ivK vJB4mrpnKoxinL9vjbJZ6670XanLiva0k2jrSwRL5xktK1u9e6KyeptawXDJc0AeKeFDpRUXp44 /bqLPYDbZjF08cKrmzd5vQBrvAx23yafdcGu0/9AYjGaH4cGVlJ5kkHa/qlrAo3CLTM5J42+6Ax pKmx3PQJCdr9jZiKUBjkfJdl6MvQjVgbLvZdykGxbB9XDutSTSjBH95gAuQHfK0JBCb0BAs1XdF PZBbJo1jA9GWVSc5LaFd0+EwB6A+dMjjkuVpRjI3IuTK3sSkzldUMP8Fd9h2F5upJDIl8NYHbJ0 8qIDjcw69EIyvZ6Qhy7JASL4iELf8jD24PATZi+2LvGRp6y3yFMIIgVK9MP93IaTtUb6iOv+KX5 YGu3IUqezxXA== X-Google-Smtp-Source: AGHT+IEzdhwxbsfQJvT+TvlDMVhfQHhV/8zH5/GstRRQwXcsCbM5ULAqTAR9M7X0213MG2Ra2+1EWA== X-Received: by 2002:a05:690e:c4c:b0:644:3850:9062 with SMTP id 956f58d0204a3-64716c75477mr9285804d50.72.1768006350765; Fri, 09 Jan 2026 16:52:30 -0800 (PST) Received: from localhost ([2a03:2880:25ff:4b::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6470d8c51bcsm5128601d50.22.2026.01.09.16.52.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 16:52:30 -0800 (PST) From: Joshua Hahn To: Bing Jiao Cc: Donet Tom , linux-mm@kvack.org, Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/2] mm/vmscan: balance demotion allocation in alloc_demote_folio() Date: Fri, 9 Jan 2026 16:52:28 -0800 Message-ID: <20260110005229.1348817-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Fri, 9 Jan 2026 23:45:57 +0000 Bing Jiao wrote: > On Thu, Jan 08, 2026 at 06:14:02PM +0530, Donet Tom wrote: > > > > On 1/7/26 12:58 PM, Bing Jiao wrote: > > > + /* Randomly select a node from fallback nodes for balanced allocation */ > > > + if (allowed_mask) { > > > + mtc->nid = node_random(allowed_mask); > > > > > > This random selection can cause allocations to fall back to distant memory > > even when the nearer demotion target has sufficient free memory, correct? > > Could this also lead to increased promotion latency? > > Hi Donet, > > Thanks for your questions. > > Yes, the random selection could select a distant node and lead to > incresed promotion latency. > > I just realized that the the fallback allocation should not weighted > by a single metric, such as node distance, capacity, free space. Hello Bing, I hope you are doing well! Yes -- this is also what I believe, and I think this idea of "how should we select demotion / allocation targets" is something that is a difficult problem (and one that may not have a single solution that "just works"). It's also a question that I have been thinking about, and what was discussed in part at LSFMMBPF last year. At the time, I made some auto-tuning weights [1] for weighted interleave based on bandwidth capacity, since the main benefit of weighted interleave is to distribute memory accesses across multiple nodes to maximize how much bandwidth the system can use at once. A follow-up was to think about how these weights could change over time, and what heuristics should be used to determine how the weights are selected. Ultimately, we agreed that the heuristics should probably be delegated to userspace, since there are just so many scenarios that could change what metrics should take priority. (Jonathan Corbet wrote a great summary of the discussion in an LWN article [2]) Coming back to this patchset, I think that all of the ideas above apply nicely here as well. What nodes should be selected for demotion and how they should be weighted is a difficult question, and one that is probably best answered by userspace and what workload they expect to use on their specific system. What I do believe though, is that an unweighted random selection / round-robin approach to selecting demotion targets might lead to some unexpected performance implications. > We need a thoroughly study before changing alloc_demote_folio(). So I think this is the way to go : -) Although, I'm not actively exploring this at the moment ;) Please let me know what you think, I hope you have a great day! Joshua [1] https://lore.kernel.org/all/20250109185048.28587-1-joshua.hahnjy@gmail.com/ [2] https://lwn.net/Articles/1016842/