From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) (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 F2E1E2EB87E for ; Fri, 9 Jan 2026 07:24:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.61.82.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767943502; cv=none; b=lRJp9nJGELa4OhtgfU1yJxnDMy4XJ9Ca3+6EqJIlNI2gPWuXzRuC74r4u7yXwY8WHe8Hjg1JEnFN4ItgMm2CUq/Q8g72KtXRcBK4c5bxZRPionTLICTOsKb6L8OjTWFmxoqjCdUyWxcsZQ74nUOEV9rPetiv27EMSDDiSMhPdG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767943502; c=relaxed/simple; bh=M1nt6I5pwMgwoNoTAbZPOfI3Q6pXAFs4F1x0MRx63TQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=e8jsGHqz1E1SonZCha9dIxSj5TW7BoiyDRSDymsQ7PFFyUjG6aqcL4HM67pyYzy5MlFvsD9lbPk0/BJI6jpN9FchnUdPcdvp4myZ+Oac4MND7MeApII1/fX3G6lvp5IL8jHhF4SvOV4kk/7aRdT+bVrApeBKiG17pxGlDL5Cplg= 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=YAMd5PRg; arc=none smtp.client-ip=210.61.82.184 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="YAMd5PRg" X-UUID: 4afa56b2ed2c11f0bb3cf39eaa2364eb-20260109 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=F8qggB+ZqQxK1gpWWS6Ztd+cnpOCo+EBfWlyX/Zk/QU=; b=YAMd5PRgKEqkVlkWbhinoK83VfI9euK8jb14MdoZxUq/thtKdbo9lr9ni7RwTWmSsU3hdNqPTJO8ehXK2jspOxawNbktaZCiALrHU/qhHw8vF7/9OSeYOCOP9Ah/GoEaNYCTCm5Fe2irTVpJxYgMKGgW9w0HFGYECGUWWxpIn0I=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.9,REQID:e6ef0cb0-b85a-47c0-a65f-a43a7573ffd3,IP:0,UR L:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION:r elease,TS:0 X-CID-META: VersionHash:5047765,CLOUDID:70199026-5093-468b-b7e7-d8195251fc6e,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:80|81|82|83|102|836|888|898,TC:-5,Co ntent:0|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: 4afa56b2ed2c11f0bb3cf39eaa2364eb-20260109 Received: from mtkmbs13n1.mediatek.inc [(172.21.101.193)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1935177991; Fri, 09 Jan 2026 15:24:54 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) 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; Fri, 9 Jan 2026 15:24:52 +0800 Received: from gcnsap21.gcn.mediatek.inc (10.17.81.22) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.2562.29 via Frontend Transport; Fri, 9 Jan 2026 15:24:51 +0800 From: Dengjun Su To: CC: , , , , , , , , , , , , , , , , Subject: Re: [PATCH] sched/rt: fix incorrect schedstats for rt thread Date: Fri, 9 Jan 2026 15:24:47 +0800 Message-ID: <20260109072451.2843331-1-dengjun.su@mediatek.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260108111632.GH272712@noisy.programming.kicks-ass.net> References: <20260108111632.GH272712@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 Thu, 2026-01-08 at 12:16 +0100, Peter Zijlstra wrote: > On Thu, Jan 08, 2026 at 11:13:07AM +0800, Dengjun Su wrote: > > For RT thread, only 'set_next_task_rt' will call > > 'update_stats_wait_end_rt' to update schedstats information. > > However, during the RT migration process, > > 'update_stats_wait_start_rt' will be called twice, which > > will cause the values of wait_max and wait_sum to be incorrect. > > Right, that looses time. Also note that I think dl has the same > issue. Hi Peter, Thanks for the feedback. Yes, sorry for miss dl class, I will update it in V2. > > > The specific output as follows: > > $ cat /proc/6046/task/6046/sched | grep wait > > wait_start : 0.000000 > > wait_max : 496717.080029 > > wait_sum : 7921540.776553 > > > > Add 'update_stats_wait_end_rt' in 'update_stats_dequeue_rt' to > > update schedstats information when dequeue_task. > > This needs a few more words on why this is correct -- notably it took > me > a little time to find the 'task_on_rq_migrating()' case in > __update_stats_wait_end() which makes this not actually 'end'. > > But then the corresponding clause in __update_stats_wait_start() > gives > me a headache: > > 'wait_start > prev_wait_start' > > I mean, wtf. Should that not equally be using task_on_rq_migrating() > ? > > Can you please take a hard look at all that and fix up things > all-round? > A complete schedstats information update flow of migrate should be __update_stats_wait_start() [enter queue A, stage 1] -> __update_stats_wait_end() [leave queue A, stage 2] -> __update_stats_wait_start() [enter queue B, stage 3] -> __update_stats_wait_end() [start running on queue B, stage 4] Stage 1: prev_wait_start is 0, and in the end, wait_start records the time of entering the queue. Stage 2: task_on_rq_migrating(p) is true, and wait_start is updated to the waiting time on queue A. Stage 3: prev_wait_start is the waiting time on queue A, wait_start is the time of entering queue B, and wait_start is expected to be greater than prev_wait_start. Under this condition, wait_start is updated to (the moment of entering queue B) - (the waiting time on queue A). Stage 4: the final wait time = (time when starting to run on queue B) - (time of entering queue B) + (waiting time on queue A) = waiting time on queue B + waiting time on queue A. The current problem is that stage 2 does not call __update_stats_wait_end to update wait_start, which causes the final computed wait time = waiting time on queue B + the moment of entering queue A, leading to incorrect wait_max and wait_sum. 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. Thanks