From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.127.230.114 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792737867; b=Q+yCpLKIU/F4HKPsmRHP5loQhIGgKOPS+/HVZ3SOYERXu/7o+FVCtaLIDUqpX7RA/guf fZPCvWTCOAng33CG3YwZQoPWgG3UWLPgxc5Z4yILvFCN1bmz8kTbvW3wcgFPUQXmDyvOt e93RLa2QGqC/nF7mA3n3+Foq62hAb5dHcaLb4HSkUfLQTp4Fbac0uB0vI0mmltUZBOatC gQ+5Df6bsaMM+ZF0+m4ytHbYF4EEl9GSJcP+PiRh1Ww/hWaiMcPUfJB12LsX7N9/301/+ j7tTHdgMzvfgbiFf1Twj5pEBsgQ1r5Xsz/8XuIOqSCDZZdIWWEB6i0Lt4dYQpPa2BzQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792737867; h=DMARC-Filter:DKIM-Signature:From:Content-Type:In-Reply-To:Subject: Date:Message-Id:X-Original-From:User-Agent:Cc:Mime-Version:To: References:Content-Transfer-Encoding:X-Lms-Return-Path; bh=RRG6U99EKeZDnYNuky91yYiF/y3AS7tMgJRzNytuW38=; b=eQa6QJOoPspBkb1ZQIRiC3nHH0Wp/P+6gEDi7XSdwT6lUIz3qWzEzsvxOOAkw8vxscJ9 /rxxrnB1H6lOPUZNn0W+upna34YraOZa/9fUJ9MDpH/61npfo/bowLpb7v6g15Lj4+F/7 KjqAWwEUSus8cuqiNywBeXusdjBYk/v4KlfuH04RwL44Rjr6OG/ssHY9dNfQ4mDHiPm6J zvJwrACk+4uzpXs/mSSOHvh5X4PznAef31p5XR33Durn9VCwFm8mDPXRGoH9K3nLNWgGZ kat9UxJ8YmsNKXKf/SPSIGDdaZ3z07jIcfKyutxN8K+Nef9N04YrdOI2n6Cf1AuvJOQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b="cpys32/L"; arc=none smtp.remote-ip=209.127.230.114 Received: from va-1-114.ptr.blmpb.com (va-1-114.ptr.blmpb.com [209.127.230.114]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A0891606A31D for ; Fri, 23 Oct 2026 06:44:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org A0891606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b=cpys32/L DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1792737860; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=RRG6U99EKeZDnYNuky91yYiF/y3AS7tMgJRzNytuW38=; b=cpys32/LRolwEFjjMEMw/5ElImdKxW3aek0sC7tkC1CNPLkRKMJvICJUrECWh/hB0z30gw O2MP7SyffSrZ+log0mKJ8xHHnjE7ajfrF8OUXcg08jUoiNFS+ZBOVIzgir2eZ3QVBuLAwS Du83PYH0Bn1iHjxPqYpSOG1+8vnBVJmr08xntzi89e3Vd7dhZxBdkMQI7XwynjBqvxw/41 62EhywzBgDtmsC6/YixqjbCOBGfR7DMX3zLMeUXX4V/SL6jFS6iWgT+g/sMtVuHugXjR7V 4yLlBgQsZIKhr4Fi+HIGJ4tpRrUFlLtHI8NtZVASvZK4v9caO8Vq75AvaYG4uw== From: "Li Zhe" Content-Type: text/plain; charset=UTF-8 In-Reply-To: Subject: Re: [RFC 0/2] mm: add source selectors to memory.reclaim Date: Fri, 23 Oct 2026 14:43:57 +0800 Message-Id: X-Original-From: Li Zhe User-Agent: Mozilla Thunderbird Cc: , , , , , , , , , , , , , , , X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 To: "Gregory Price" References: <20261019141401.11927-1-lizhe.67@bytedance.com> <30457046-a662-4ff7-a6a8-100398d7a806@bytedance.com> <179264138036.2549665.17429111144570830454.b4-reply@b4> <9b715272-3ed9-42da-a6ae-467e8ae00c0b@bytedance.com> Content-Transfer-Encoding: 7bit X-Lms-Return-Path: On 10/22/26 10:11 PM, Gregory Price wrote: > On Thu, Oct 22, 2026 at 05:43:49PM +0800, Li Zhe wrote: >> On 10/22/26 11:56 AM, Gregory Price (Meta) wrote: >> >> So userspace cannot rely on one write to memory.reclaim to produce a >> final per-node distribution. The intended usage is a feedback loop: the >> controller observes the memcg's resident distribution, chooses the source >> nodes it wants to relieve, applies source-scoped reclaim pressure, >> observes the new distribution, and iterates. >> > I think the critical question is what CAN userspace rely on? > > We can make a bunch of feedback loop interfaces, but there's no > guarantee they'll actually be useful. The reliable part I currently want to claim is narrow: userspace can ask memory.reclaim to apply reclaim pressure to memcg memory resident on the selected source nodes. It should not rely on a single write to produce a final net per-node footprint. The existing memory.reclaim interface is also a best-effort reclaim request rather than a deterministic placement primitive; this patch only adds a way to select where that reclaim pressure is applied. > >>> At the very least i think you need to add details in your cover that >>> demonstrates the process of doing something like per-node resident >>> ratios, and show that it works as you intend. >> Agreed. I will update the cover letter to make this model clearer. I >> will also make clear that source=nodes is not a final net per-node >> footprint guarantee and does not change memory.reclaim completion >> accounting. >> > To be clear, I think not just making it clearer, but if you can show > some tests that demonstrate the reliable behavior of the interface > extension under different scenarios - that would be compelling. That makes sense. I will run more detailed tests across different scenarios and include the results in v2. Thanks, Zhe > > ~Gregory