From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A70421FF5E3 for ; Sat, 16 May 2026 03:08:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778900903; cv=none; b=IbDkE1vSJoS2ngkQ9JpWQs3XbrmAOOxXgzxY819/fqG+ygp95SW0yjob0skjd2MBcrtpCxedvVKdADUz2DXzR6jKIYChbin0lsYdt7Kd7De0/QAnsktbTUVo2gR+8XFnMSsbPU7H+BbtLetR2H878j/ww5hfpbI1QV2U7ifN0p4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778900903; c=relaxed/simple; bh=De2hxXjelXLIk6PTP47Rzp3UeCt6uyDrKW3n3h2Jj4s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m42spQWaDjUupOCxjIJ9/+p5s3wJhPGvmX0+SeR8eUpBQxE0fokLcQcnx8BHGiJ9W8uZqWczVJpNeIco2IGKKYpCwQOUyKpY2zJuEjXjos26DblwgraOarsUXkIp7krxbLZwet8bBcxVs76PZD/nplSfqpJiZB7mShcdLl1X80Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20251104.gappssmtp.com header.i=@layalina-io.20251104.gappssmtp.com header.b=fTSOpnqy; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20251104.gappssmtp.com header.i=@layalina-io.20251104.gappssmtp.com header.b="fTSOpnqy" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-44a74032ff8so269408f8f.1 for ; Fri, 15 May 2026 20:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20251104.gappssmtp.com; s=20251104; t=1778900900; x=1779505700; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=B+BgJ+JcnmfxGMf1H17dvufrUNSH2R/540QSZv4B4T0=; b=fTSOpnqy4Fbze73DeL9a47OXz9EZ31xM/g72DQhbg++Ff+wxbj/k1Z+09gv/JL48g3 BWmcouZJA/ALd++NA6MiGt08ky2MWZqOXGMM7+tGVlG0vP+9WDS8CvN/4+kwjV5tKKUo 34+1Vx6L1ccgmbkCEDdDjPq0i4q+iUe9cLoM0u93vuKhBz78CZOHpkx5bfSBfvgiFFGc haDhCAk7wl2/6DLazX1jmLDGRXBkZ2dkp9EtvjE2eQwVs+l+6iMt5ZTiH1AJVCq3xVPS geeS9ZVZ2BSBhbtlakMSuAoxdrTbkH5U4R/X9A4klvLyO73tD169NFmGdaOGTQ7jw6Vs xu0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778900900; x=1779505700; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=B+BgJ+JcnmfxGMf1H17dvufrUNSH2R/540QSZv4B4T0=; b=pwE5KLR2pzm38x1OTu5PjgPh2DMveByGUZQqE0G+9vgup2AlUjmGNfmhftVSb83ZGq 9UyX8rSTCQii8fqsyH8oMsOV1QKG9WD6+l4yf3v7xAvEXsQnOGbIs/0o7OCCwaE63SBg 5BMBbzqbe195wF3QDi6/5dIdgMv/MMlG59XGOKDHH5ozPd/agnCPnXU5lcVFgSriKrm7 gqQvWrnZJu9lkXi4j+oQWQykMAB0fd+f72IMpmZKFW5J25U04VL0UurHc27lYat2vqY8 30pu9Jf+/WwQuPVqtSbqwiHM4uujqa9dSAAp4TXRcff4tNiarmNJ4hMtqi4mPjGY7ivD HfxA== X-Forwarded-Encrypted: i=1; AFNElJ8o44IkkXm4iOffKZ5qabkq1TKi270vPqjcrahTkqV25UIzAeBi0rObJDt32Z3jres9LMmBKIwi1DrNTlo=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7f38mtOnP/5eDUKQa1+aJs4P8E7j/WjPFLdKU2yjpFmmSJAEq uNxq+Vafe44DRzf9c4BUl+6/s/SgHqnMCHlnpTvJaShUNjiRQFrZR/XsPKZyE6wnQ8U= X-Gm-Gg: Acq92OFwcAGz6WRC4196RPhipDII7WBJKMtQzsGdCPia5Zlcp2baz9JvlVBTH8c3WU2 xDdWVi3IzJBmJ6UqjquDT0GG4ivef5cSy/ZzPVkCx1dSLiYoE5LFPKkEGNU4W0n4hOesCGxDvfZ 9lhdtT8JHXSNqRG87Ny1CpD52uiem86ol4mfa6VUIcj11bLiA5L3OJYZKnfCYc9cPFuL2DxXzv2 tgm2zqSndJBBBHSxUFBbcjX7FD5OaNea+P2wXObNmvKF43p8SCappJh2gfpXxkeuIftaR3UCa1m WGw4CH6h5SfsWCLy4QvyKfDofc5+LB7g0Oh+Rop2uHwz0VtS2pME2DbIoPIj0pFDMXGG1iBx4x3 sZkQoneUPSxOtNytCMHEFS2a9Wcb0HtGPl+ljBf7x52/QW26Iw2T+pzkh/TEiQbUzVT872B60wa WLqcoxk7t/SJnMUdffqas0y2fW5w== X-Received: by 2002:a05:6000:250a:b0:45d:4b37:7fcf with SMTP id ffacd0b85a97d-45e5c58951emr8858808f8f.15.1778900899984; Fri, 15 May 2026 20:08:19 -0700 (PDT) Received: from airbuntu ([149.40.48.89]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9ed2ffdfsm17027129f8f.15.2026.05.15.20.08.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 20:08:19 -0700 (PDT) Date: Sat, 16 May 2026 04:08:17 +0100 From: Qais Yousef To: Tim Chen Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , "Rafael J. Wysocki" , Viresh Kumar , Juri Lelli , Steven Rostedt , John Stultz , Dietmar Eggemann , "Chen, Yu C" , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH] sched/fair: Call update_util_est() after dequeue_entities() Message-ID: <20260516030817.e2ysxb2s6pbq4nrr@airbuntu> References: <20260512124653.305275-1-qyousef@layalina.io> <15a0cfb8457b7d9d767e7f2d2bcfd56b155f6c0b.camel@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15a0cfb8457b7d9d767e7f2d2bcfd56b155f6c0b.camel@linux.intel.com> On 05/15/26 11:35, Tim Chen wrote: > On Tue, 2026-05-12 at 13:46 +0100, Qais Yousef wrote: > > update_util_est() reads task_util() at dequeue which is updated in > > dequeue_entities(). To read the accurate util_avg at dequeue, make sure > > to do the read after load_avg is updated in dequeue_entities(). > > > > util_est for a periodic task before > > > > periodic-3114 util_est.enqueued running > > ┌───────────────────────────────────────────────────────────────────────────────────────────────┐ > > 183┤ ▖▗ ▐▖ ▖ ▗▙ ▗ ▗▙▖▖ ▖▖ ▖ ▖▖ ▗ ▟ ▗▄▖ │ > > 139┤ ▐▛█▜▙▞▀▄▄▞▚▄▟█▞▙█▄▟▀▚▄▄▞▚▄▄▟▀▀▛▄▝▄▄▄▙█▛▛█▛▜▛▄▄▀▄█▙▛▛▛▙▄▀▄▄▖▜▄▟█▟▀▜▟▄▜▀▄▄▟▙▖ │ > > 95┤ ▐▀ ▘ ▝ ▝ ▝▘ ▘ ▘▘ ▝▘ ▝▘ ▝ ▝ ▀ │ > > │ ▛ │ > > 51┤ ▐▘ │ > > 7┤ ▖▗▗ ▗▄▐ │ > > └┬─────────┬──────────┬─────────┬──────────┬─────────┬──────────┬─────────┬──────────┬─────────┬┘ > > 0.00 0.65 1.30 1.96 2.61 3.26 3.91 4.57 5.22 5.87 > > > > and after > > > > periodic-2977 util_est.enqueued running > > ┌─────────────────────────────────────────────────────────────────────────────────────────────┐ > > 157.0┤ ▙▄ ▗▄ ▗▄▄▄ ▗▄ ▗▄▄▄▗▄▄ ▗▄▄▖ ▄ ▄▄▄ ▄ ▄▖▖ ▄▄▄▄▄▖▖▝▙▄▄▄▄▄▄▖ ▗▄ │ > > 119.5┤ ▗▄▌▘▀▀ ▀▀▀ ▝▀▀▘▝▀▀▀ ▝▀▘ ▝▀▀▘ ▀▝▀▘▀▀▀▘▝▀▀▀▀▀▀▀▘▝▝▀▀ ▀ ▝▝▀ ▀ ▀▀▀▀ │ > > 82.0┤ ▟ │ > > │ ▌ │ > > 44.5┤ ▌ │ > > 7.0┤ ▗ ▗▖ ▌ │ > > └┬─────────┬─────────┬──────────┬─────────┬─────────┬─────────┬──────────┬─────────┬─────────┬┘ > > 0.00 0.65 1.30 1.95 2.60 3.25 3.90 4.56 5.21 5.86 > > > > Note how the signal is noisier and can peak to 183 vs 157 now. > > > > Fixes: b55945c500c5 ("sched: Fix pick_next_task_fair() vs try_to_wake_up() race") > > Signed-off-by: Qais Yousef > > --- > > > > This is split from [1] series where I stumbled upon this problem. AFAICS it > > needs backporting all the way to 6.12 LTS. > > > > [1] https://lore.kernel.org/lkml/20260504020003.71306-1-qyousef@layalina.io/ > > > > kernel/sched/fair.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 728965851842..96ba97e5f4ae 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -7401,6 +7401,8 @@ static int dequeue_entities(struct rq *rq, struct sched_entity *se, int flags) > > */ > > static bool dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags) > > { > > + int ret; > > + > > if (task_is_throttled(p)) { > > dequeue_throttled_task(p, flags); > > return true; > > @@ -7409,8 +7411,9 @@ static bool dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags) > > if (!p->se.sched_delayed) > > util_est_dequeue(&rq->cfs, p); > > > > + ret = dequeue_entities(rq, &p->se, flags); > > util_est_update(&rq->cfs, p, flags & DEQUEUE_SLEEP); > > I thought that util_est_update() was called intentionally before dequeue_entities > to update the utilization of task p up to this time right > before the dequeue. Then dequeue_entities() is called later > with up to date task utilization estimate of p. No. If you look at older versions of dequeue_task_fair() you'll see it was done at the end. util_est is a holding function, it should remember the last util_avg value at dequeue, so the updates must happen first. > > Perhaps util_est_update() should be moved before > util_est_dequeue() so the updated utilization of p > is subtracted from the rq utilization. We actually should subtract the old value always before updating it. The update happens only at dequeue. My rampup multiplier patches introduces updates for running tasks, but has to do the dance of subtract, update and re-add otherwise you'll end up with weird util values at the rq. > > @@ -8002,10 +8002,10 @@ static bool dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags) > return true; > } > > + util_est_update(&rq->cfs, p, flags & DEQUEUE_SLEEP); > if (!p->se.sched_delayed) > util_est_dequeue(&rq->cfs, p); > > - util_est_update(&rq->cfs, p, flags & DEQUEUE_SLEEP); > if (dequeue_entities(rq, &p->se, flags) < 0) > return false; > > > Tim > > > - if (dequeue_entities(rq, &p->se, flags) < 0) > > + if (ret < 0) > > return false; > > > > /*