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 108EE3002D7 for ; Fri, 28 Nov 2025 09:29:35 +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=1764322180; cv=none; b=DsoH/54OZORq9sNWDhgaJs5kwSCYCteHiSHZD1s5gE8FyEvcaEdYAiEFZY1aaBBmjAmPT5UAd+F+2HRf6RglJVKpBI3hnDgSiD4EG8QyULm8iHSfhGYkLQbAMz2kTs5AI3GJMF5tRvImdo//9K2J3LVeCWT8eglMFJVlLIXi8y8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764322180; c=relaxed/simple; bh=YbrpduCOAsPFznoJ7oXo7i48h6YV68/GEvfB9Otwwbs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZysUOCWiCxAhpuOllIuiVpAgXWGitYPaaY4r0IwI9Hvu84p8F00natlvbrdfkCjdrheyy1YbBO7YlvAETXKKSwwd6smErhX+66O/dowHSReNs01ukW7gptEFyeEj2FPM80VEB40ZxY1vwb7OFkwj7Yt5/z6nZPsIFp41lHqDI9o= 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=C6/33AU0; 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="C6/33AU0" 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=YbrpduCOAsPFznoJ7oXo7i48h6YV68/GEvfB9Otwwbs=; b=C6/33AU0u6f3++8lX2JbbPBTe5 QIYOlLHyB2qMJpddx2Y20+IdwMwiNmyNjukmNdYk3d3nANwF3aslStzArhQbhLlgVfi408LpP0eAq kNe4GLWKX56xTINl3UqD8uuenfGwTyrJ+Yzhr/l1+hpVCgThw/IpDukssCFY91Ps6Aiqnu4uOY/72 cg1WUTWSwpocfjfs/XuCEW7NVpSv+uttVcxPdtQ/06ixHhui1tSeS7N/se+uAgmNSxfMSd1EB1yd+ EBaeofr6sVXal6cOU1ifEk2PZF9YsCoOHRMb++uwkOqDTCwUFXqJ55O62WieyWdCTaHpxGCZXltq/ kv3KZmRA==; 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 1vOtvX-0000000BdID-2O4H; Fri, 28 Nov 2025 08:34:03 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 9C409300230; Fri, 28 Nov 2025 10:29:23 +0100 (CET) Date: Fri, 28 Nov 2025 10:29:23 +0100 From: Peter Zijlstra To: wangtao Cc: mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, liulu.liu@honor.com, bintian.wang@honor.com Subject: Re: [PATCH] sched: fair: make V move forward only Message-ID: <20251128092923.GC3245006@noisy.programming.kicks-ass.net> References: <20251128081118.20025-1-tao.wangtao@honor.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: <20251128081118.20025-1-tao.wangtao@honor.com> On Fri, Nov 28, 2025 at 04:11:18PM +0800, wangtao wrote: > V is the weighted average of entities. Adding tasks with positive lag or > removing tasks with negative lag may cause V to move backward. This will > result in unfair task scheduling, Have you actually read the paper? Why do you think this breaks fairness? > causing previously eligible tasks to become ineligible, shorter > runtimes, and more task switches. None of that is a fairness issue. Those are issues related to when, rather than how much time is given. > Making V move forward only resolves such issues and simplifies the code > for adding tasks with positive lag. It breaks a metric ton of math. Which you don't provide updates for. Yes, the paper is light on dynamic behaviour, but please don't disregard the math like this. Either stay inside the constraints laid out, or provide coherent alternatives. Notably EEVDF is in the same class of scheduling functions as WF2Q and both provide better lag bounds than the simpler WFQ class of schedulers. The 'zero-lag point is the weighted average of the entities' is a fairly core tenet of EEVDF. Mucking with this *will* mess with the lag bounds. The delayed dequeue feature tries to address some of these concerns by keeping non-eligible (negative lag) tasks on the runqueue until such time that they become eligible (approximated by getting picked again) at which point they get removed (and any positive lag gets truncated, as if they were removed at zero-lag). As a consequence you will have much less removal of negative lag, additionally such tasks will be eligible the moment they come back. Also, there is the small matter that your patch simply does not apply.