From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) (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 B0B40396B6D for ; Wed, 14 Jan 2026 11:55:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.244.123.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768391751; cv=none; b=Tlo/AmCXBfRn0FJISj5iPDbQOHTNa+s4UvrdLjyX4qcaS9+HmGO+lfW4Kz/5MtDwWVdvSLHguWwelpY4pzfET9PMls+YSiUvxDoPRwrgvTvYkTHWcb5UrMPVLwwHqTdoYKrQJP5m4r3vIadfY/cTDFES2S6tHt4+f4uJOi/PgyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768391751; c=relaxed/simple; bh=DG3KsmsqIYPYzriL9H794qx3d6RF+g4p7gSwAJk2qeI=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WZLMIYKaWXG6dgFOvvX//CFNSMZfpGhH8zJER6VUdFm7m2vYeZCzEVVoEQgRMD9acak1Mc1U+BEyHEBI8fJqHvKuwud9OJHRddjoEuZxV1bFOblhRNe+/2hW9FaJ2PSaxO6eO3j5W0zfwi7JN8lCPFvkum3nwUK/UVOdK2k3Tq8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com; spf=pass smtp.mailfrom=mediatek.com; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b=nBvJ7pQB; arc=none smtp.client-ip=60.244.123.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mediatek.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="nBvJ7pQB" X-UUID: efe0b5cef13f11f0942a039f3f28ce95-20260114 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=fATf/St2y2YgIn8oxgkSgNLL6dxB/Sz4b5lYp4lukmY=; b=nBvJ7pQBl+rUhepdxlTYUewLWBxyYTrV9q1X6WkU5lc0HTB/Yf051M0Bai0HX64yhPciP0GQPeJb9GcAzd/HY9d5sHlCcogZIm7BspCex6XkP/tL4NGA5bc+eTTArZSvStbcJKe3pGAcXc/u8LmbVviQV8o3fjFCDHE8+Jae9vc=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.9,REQID:45805a38-8405-4dc3-b195-9d1b0acf347b,IP:0,UR L:0,TC:0,Content:3,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION:r elease,TS:3 X-CID-META: VersionHash:5047765,CLOUDID:6efd85ef-16bd-4243-b4ca-b08ca08ab1d8,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:80|81|82|83|102|836|888|898,TC:-5,Co ntent:4|15|50,EDM:-3,IP:nil,URL:0,File:130,RT:0,Bulk:nil,QS:nil,BEC:nil,CO L:0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: efe0b5cef13f11f0942a039f3f28ce95-20260114 Received: from mtkmbs10n2.mediatek.inc [(172.21.101.183)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 579765865; Wed, 14 Jan 2026 19:55:35 +0800 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by MTKMBS14N1.mediatek.inc (172.21.101.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Wed, 14 Jan 2026 19:55:34 +0800 Received: from gcnsap21.gcn.mediatek.inc (10.17.81.22) by mtkmbs11n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.2562.29 via Frontend Transport; Wed, 14 Jan 2026 19:55:33 +0800 From: Dengjun Su To: CC: , , , , , , , , , , , , , , , , Subject: Re: [PATCH] sched/rt: fix incorrect schedstats for rt thread Date: Wed, 14 Jan 2026 19:55:31 +0800 Message-ID: <20260114115533.2959537-1-dengjun.su@mediatek.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260112163814.GP830755@noisy.programming.kicks-ass.net> References: <20260112163814.GP830755@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-MTK: N On Mon, 2026-01-12 at 17:38 +0100, Peter Zijlstra wrote: > On Fri, Jan 09, 2026 at 03:24:47PM +0800, Dengjun Su wrote: > > > For __update_stats_wait_end(), task_on_rq_migrating(p) is needed to > > distinguish between stage 2 and stage 4 because they involve > > different > > processing flows, but for __update_stats_wait_start(), it is not > > necessary > > to distinguish between stage 1 and stage 3. > > > > As for adding the condition wait_start > prev_wait_start, I think > > it is > > more like a mechanism to prevent statistical deviations caused by > > time > > inconsistencies. > > It looks like nonsense to me.. since you have a test-case, could you > see > what this does for you? > > Specifically: > > - it ensures that when not in a migration, prev_wait_start must be 0 > > - it unconditionally subtracts; unsigned types are defined to wrap > nicely (2s complement) and it all should work just fine. > > --- > > diff --git a/kernel/sched/stats.c b/kernel/sched/stats.c > index d1c9429a4ac5..144b23029327 100644 > --- a/kernel/sched/stats.c > +++ b/kernel/sched/stats.c > @@ -12,8 +12,10 @@ void __update_stats_wait_start(struct rq *rq, > struct task_struct *p, > wait_start = rq_clock(rq); > prev_wait_start = schedstat_val(stats->wait_start); > > - if (p && likely(wait_start > prev_wait_start)) > + if (p) { > + WARN_ON_ONCE(!task_on_rq_migrating(p) && > prev_wait_start); > wait_start -= prev_wait_start; > + } > > __schedstat_set(stats->wait_start, wait_start); > } Hi Peter, I have confirm in my current test case, adding this change or not have no impact. I think this is reasonable, task_on_rq_migrating(p) should be true in my test case. Base on original patch that adds this, I think the logic of __update_stats_wait_start is: 1. If migrating and the time is updated normally, it records the waiting time on the previous queue. 2. If time is abnormal, it updates wait_start to the current time. For migrating, it will discards the previously counted waiting time on the previous queue (perhaps this statistical value itself is abnormal). According to the current modification, if there is a time abnormal, wait_start will not be updated to current time. Partial fragments of the original patch are as follows. --- diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9a5e60f..53ec4d4 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -738,27 +738,41 @@ static void update_curr_fair(struct rq *rq) } static inline void -update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se) +update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se, + bool migrating) { - schedstat_set(se->statistics.wait_start, rq_clock(rq_of(cfs_rq))); + schedstat_set(se->statistics.wait_start, + migrating && + likely(rq_clock(rq_of(cfs_rq)) > se->statistics.wait_start) ? + rq_clock(rq_of(cfs_rq)) - se->statistics.wait_start : + rq_clock(rq_of(cfs_rq))); }