From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (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 928533F4DF3 for ; Tue, 28 Jul 2026 07:56:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785225403; cv=none; b=YNWNNj+c/2JdG7hpIQhXLW9TulCgixniihC+SUc+YaRVNai6AtTqxNpH3RZN+RrPL6vh9pOUDyKd1JI3bL/RZsizObCmqaIFtrpJBxYxkZKZwjUn3FOblvNP+YLPtDF2b8qdbpj8hqhDrvl1ZLtfQ3aJhOaEpdilqW48d4DY8XY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785225403; c=relaxed/simple; bh=vEtORrUL6kXcRUI5a96daGiliGU4beObCfOmy3xcrYI=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=f7PnK0F96gutaAjLuZR2XASQcSx5/lOy+wNMdHnf51setCuBx1TiNbeXjd2JzLOFVcGlyVggrBZwfXVLj2cJxTI3E2FGXWSDl0D/a1HswZ5ygdHZKaAkbxE/6BUsNJDhf68DgmrB3NhtBtroS8gzF0ki68oVswbNy0wmKjpvQdA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=MbbrfrZL; arc=none smtp.client-ip=91.218.175.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="MbbrfrZL" Message-ID: <2dfaa2e4-4552-42b5-9716-a10207b5d22b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785225398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YJJwlF00MVf4iCewWLhM6kGMDxHE6NKxJNgkHiKKrHo=; b=MbbrfrZL+jMqQNC29f+DASShgyRJn98cnZnLvs66gNmVW+KWn3DGUkeh2pIp1+DDNpAQGs knz5Yx3a2lVJkBlsC5XUrAz75x6Uu1ZwHgwDequwr7OHEMuJ9qFudDk6eHb5x63VcdwTWj mhIPDLSGyRrsIDh+sN9R+P5WxjlxkV8= Date: Tue, 28 Jul 2026 15:55:46 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Cc: cui.tao@linux.dev, Johannes Weiner , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Tao Cui Subject: Re: [PATCH 0/2] sched/psi: fix trigger window arithmetic To: Suren Baghdasaryan References: <20260724041146.510027-1-cui.tao@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Tao Cui In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2026/7/27 14:10, Suren Baghdasaryan 写道: > On Thu, Jul 23, 2026 at 9:12 PM Tao Cui wrote: >> >> From: Tao Cui >> >> Two narrow numeric bugs in the PSI trigger-window arithmetic, both from >> the original psi monitor (0e94682b73bf) and both only visible for trigger >> windows larger than ~4.29s (UINT32_MAX ns). >> >> 1/2 window_update() estimates the stall growth inside a partially-elapsed >> window as `prev_growth * remaining / size`. `remaining` is a u32 but >> win->size is a u64 and may be up to 10s (1e10 ns), so for large windows >> it truncates and the interpolation collapses; `prev_growth * remaining` >> can also overflow u64. Use a u64 `remaining` and mul_u64_u64_div_u64(). >> >> 2/2 psi_trigger_create() scales window/threshold us->ns with >> `* NSEC_PER_USEC`. NSEC_PER_USEC is `long`, so on 32-bit the multiply >> wraps for multi-second windows (a 10s window is stored as ~1.41s). >> Cast to u64 first. >> >> Neither path is the scheduler hot path (update_triggers() runs at >> trigger-evaluation rate), and small-window triggers are numerically >> unchanged. >> >> Demo of 1/2 -- 10s window, previous window was 100% stall, polled each >> 1s, trigger "some 5s 10s". Estimated growth (seconds) inside the window: >> >> elapsed current(u32) fixed(u64) >> 1 1 10 >> 2 2 10 >> 3 3 10 >> 4 5 10 >> >> With the current code the trigger waits for the actual stall to reach the >> 5s threshold (~4s in) instead of firing once the run-rate predicts it >> (~1s in): a ~3s delay on the first window of a stall. > > This looks like a duplicate of the series posted by your collegue at > https://lore.kernel.org/all/20260717102824.985950-1-guopeng.zhang@linux.dev/ > Hi Suren, You're right -- this duplicates Guopeng's series. He and I found this issue together a while back, and his submission already covers it, so I'm withdrawing mine. Sorry for the extra noise. Thanks, Tao >> >> Tao Cui (2): >> sched/psi: fix trigger window growth interpolation for large windows >> sched/psi: convert trigger window/threshold to ns in u64 >> >> kernel/sched/psi.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> -- >> 2.43.0 >>