From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8798D3911C0 for ; Tue, 4 Aug 2026 06:09:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785823778; cv=none; b=KM28tZ86I/ZtrvUp5g1250+nttTwNSHzmJhkNn0HzcQrpqO3CElqyjTWriTDSIlKWGjP1iaTOQ5CmMwznJ0h2Ew5QmvlJhhqsStoSbdjlKWpH8eo3m6B3X/0eRyM2RrwN136pKT0ExMaRcYRCGp0yrXBxZtbDON+A7cmJWsToxs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785823778; c=relaxed/simple; bh=ykPKMcwKSSFfqi80P4wkJBXVo+tmyM+pd4QKb2GyhXg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=j7rdG+hATkgjQMz/qy0nZkeg5wFtA2V3D5JkXvIj6g9JtaokUaHvifilLw/1cRoPhcRh1Rq48C7iys1hxpsxYLBfJk3nEg72ZUlAjcrneEOpbifp1n0/vmItD7iQEv3BjXA7K3CUQ5BwcBuzNcyCiGXvXD/Xc3CzbTt0rRB8Pb0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com; spf=pass smtp.mailfrom=126.com; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b=BDVfc3zn; arc=none smtp.client-ip=220.197.31.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=126.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b="BDVfc3zn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; bh=ELoa2OdHWgEhqAZ/thXTcChs7/RCfkzgsTltWe0Lvaw=; b=BDVfc3zn8yYGezQPQImHOxvr1wSOcL+Jqulk8n4f4f5vcm0daOstdYGUobFtsJ VSXDiq5THFRTielrVdnBDN5GbrvFNC8ztoiqZUZ/OkVqqT8MpjbCUf5Myh4JCeDh xiu/0uV5l6YZgcnMNnBRY75N7p4RBlbgV/GnXN2EJyepE= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-4 (Coremail) with SMTP id _____wD3L4LHgXFqNIi4Ew--.50641S2; Tue, 04 Aug 2026 14:08:08 +0800 (CST) Message-ID: <6A7181B4.8030807@126.com> Date: Tue, 04 Aug 2026 14:07:48 +0800 From: Hongling Zeng User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: Zhan Xusheng , zenghongling@kylinos.cn, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com CC: linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com Subject: Re: [PATCH] sched/numa: Fix scan period for remote private faults References: <20260804030731.539809-1-zenghongling@kylinos.cn> <20260804034423.3786720-1-zhanxusheng@xiaomi.com> In-Reply-To: <20260804034423.3786720-1-zhanxusheng@xiaomi.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3L4LHgXFqNIi4Ew--.50641S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxGrykArWkZFWxtF4fuw4kZwb_yoW5AFyfpa yqgF92ya1kJw1rKF129w40qa4fZw4rKry7Ja4Ygr9Fvwn8uryrtF4Ygw4Uua4UCwn7ua4F va13trsxCF1qvaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j4Hq7UUUUU= X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBoAiJWmpxgcgYWQAA3o 在 2026年08月04日 11:44, Zhan Xusheng 写道: > From: Zhan Xusheng > > On Tue, Aug 04, 2026 at 11:07:31AM +0800, Hongling Zeng wrote: >> This is wrong because for remote private memory, we should continue >> to the ratio calculation which can speed up scanning to migrate the >> memory to the local node. > I don't think the ratio calculation actually speeds scanning up in that > case, though. For the pure remote-private accesses you describe > (shared == 0, private > 0): > > ps_ratio = private * NUMA_PERIOD_SLOTS / (private + shared) > = private * 10 / (private + 0) > = 10 > > which is >= NUMA_PERIOD_THRESHOLD (7), so it takes the first branch: > > int slot = ps_ratio - NUMA_PERIOD_THRESHOLD; /* 3 */ > diff = slot * period_slot; /* > 0 */ > > and numa_scan_period is *increased* (scan slower), not decreased. The > speed-up (else) branch is only reached when both ps_ratio < 7 and > lr_ratio < 7, which pure-private accesses (ps_ratio == 10) never satisfy. > > So dropping the early return here doesn't speed scanning up; it just > grows the period by ~3 slots instead of doubling it. That might still be > a reasonable change, but the justification as written describes an effect > that doesn't seem to happen. Could you double-check, and share some > before/after numbers on a remote-private workload? A scan-rate change > like this really wants data behind it. Thank you for the detailed review. Your analysis is completely correct. You're right. The original commit message incorrectly claimed this would "speed up" scanning. The actual effect is changing from unconditional doubling to a ratio-based adjustment (which still slows scanning, but less aggressively). I've updated the patch based on your feedback: [PATCH v2] sched/numa: avoid doubling scan period for remote private faults > > Two smaller things: > > - The comment rewrites (ps_ratio -> "private", lr_ratio -> "local") look > like a reasonable cleanup on their own, but folding them into a > behavioural change makes the patch harder to review -- perhaps split > them out. (The lr_ratio branch also keeps the "shared ... moved by > other tasks" sentence, which no longer fits a local-dominant branch.) This is a good point. For now I've kept them together since both changes address the same underlying issue (misleading comments about what the ratios represent). If this version is acceptable, I can submit a separate cleanup patch in the future if needed. > > - This is the same early return that other in-flight patches touch (the > numa_faults_locality reset thread, where Peter suggested sharing the > tail with the normal path). It may be worth coordinating so the > changes don't collide > > Thanks, > Zhan Xusheng I'll check for coordination with other in-flight patches before the next submission. Thank you again for catching the fundamental issue with the original justification and for the detailed suggestions on how to improve it. Best regards, Hongling