From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 9F0DA388E4C for ; Mon, 23 Mar 2026 09:57:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774259857; cv=none; b=PdTuFLuF71JJfG4Dz/oPzdpxnsEDa8rQdyzjfz+UeDB0eZMFu1oz4W+Jl37wCqsdGFrwVVYgHNdEogggwM9hfrYuauFZrG8MNy8Ewcb0FjTNwT97o1+ANLHgG2hy3kPWaciMh6orn3khwnjlEkzzDCqb8TPnDLVcIFyNE+Lu328= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774259857; c=relaxed/simple; bh=OmnZBuCStskViXN7QaJAIZAZtlXSD9iJcRv/j18o9cY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uh6Xtqrmg7BbLRsfLZgZTC6kILKZzwwVKPdBBGKe2LO+ZYJaVcUJTK2KxJk/v6zsx1JV4lCgnKYRpN6TwZIq9U/vhXzsYTlm9ozCEjW3Ph5s9lwS1Txj0mUWsaa/j6MEU0gvubgUJsFiD+6srljNPh8eAmvZ2LMgnw7WomUMhzc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=dNeWuvC5; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="dNeWuvC5" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=LxrfMp87jBuG7GBgvpUPE1kDlMLo3O997xMnPaD+MSU=; b=dNeWuvC5R1vteiNPA0kAsWyFw+ Pjc5SCRvtxELOMwpcXm7YuqNmpeW241f8m60/mt+Or6TqMr/0lyF2FFvGi+KYkfQEKjr8Jbrj43hz jbunOEI+CkSSR+VrtgyDE0T6krtz1ZC0aOADWa+7TAutm0WzNcG+ewPRfdmwXG1oohwj9OdP0ds/h kMGuu/sGcyUtk8hEoSQVf+9IK/6keJCAu0SETxKLn2SFaGTQyM/5yP4PNVna4P/v5wFKY4U2CqQoV liiO7wQ060SgrpGFCYzfeArsTmGmsYfJD+2z42mIbHYshTcyEn3bBdnn5WwKzLY0dCZoFzEe7jJDb C9yzvmdA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w4c2I-000000019mS-0Vgl; Mon, 23 Mar 2026 09:57:26 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 10825300346; Mon, 23 Mar 2026 10:57:25 +0100 (CET) Date: Mon, 23 Mar 2026 10:57:25 +0100 From: Peter Zijlstra To: Vincent Guittot Cc: Zicheng Qu , mingo@redhat.com, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, tanghui20@huawei.com, zhangqiao22@huawei.com Subject: Re: [PATCH] sched/fair: Update zero_vruntime after clearing on_rq in dequeue_entity() Message-ID: <20260323095725.GZ3738010@noisy.programming.kicks-ass.net> References: <20260319112146.2319561-1-quzicheng@huawei.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=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 23, 2026 at 08:52:21AM +0100, Vincent Guittot wrote: > On Thu, 19 Mar 2026 at 12:43, Zicheng Qu wrote: > > > > When dequeuing the current entity (cfs_rq->curr) in dequeue_entity(), > > the cfs_rq->zero_vruntime is updated via update_entity_lag() -> > > avg_vruntime() -> update_zero_vruntime() while curr->on_rq is still 1. > > This means the current entity is still included in the zero_vruntime > > calculation. > > curr is not included in zero_vruntime but added when computing > avg_vruntime so zero_vruntime is not impacted when curr is dequeued It is, we explicitly add curr back in. > > However, immediately after this, curr->on_rq is set to 0, which should > > change the avg_vruntime() result. Without re-updating zero_vruntime, the > > stale value may be used in subsequent task selection paths: > > > > schedule() -> ... -> pick_task_fair() -> pick_next_entity() -> > > pick_eevdf() -> vruntime_eligible() > > > > If entity_tick() -> avg_vruntime() -> update_zero_vruntime() is not > > triggered in time between dequeue and the next pick, vruntime_eligible() > > may use an inaccurate cfs_rq->zero_vruntime. This can potentially cause > > all tasks to appear ineligible, leading to NULL pointer dereference. This makes no sense. One entity worth of vruntime should not affect things to the point of overrun. Yes, it is true that zero_vruntime != avg_vruntime() right after a dequeue, but that doesn't matter. vruntime_eligible() does the same math that avg_vruntime() does and takes this difference into account. As long as zero_vruntime is close 'enough' to avg_vruntime, all the deltas are small and nothing overflows.