From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta20.hihonor.com (mta20.honor.com [81.70.206.69]) (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 0E486358D2A for ; Thu, 8 Jan 2026 07:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=81.70.206.69 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767858042; cv=none; b=NznqHXOqLbvVOnjsryn6KdC04cd32GmNg+w8UdWYoKZI0/4RK76q2pR/QMkB4/zV0h4TobnvjQi+CUvxUNqunXRT4ioguEzHfp3ngPhB23msR8RhyWOMRS3lcggK8BcsOFCTIRxcF217/Mj4nz+fYr5VQA9tf1gqYzbbVCDh9vo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767858042; c=relaxed/simple; bh=sjJOTsi18jFp4E1kKLQBDMI9a4aLsJ+ntjxbIfWcHNU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=j2Fg/5Q0yZJSTElaZX6tZRflSeCL9bfYDYd2NS/sO0JrYBA5ayZC5rRgpBWTXOElFA674aCrTb8hmbt2ZxVklPPke1B/Nsa5FRUQLNgU83jANt4CLzxAMODpd0dmqShqUuknxVr8u62JAWkq1Flg1GCj2mddRqF3Bey6uMPEBC0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=honor.com; spf=pass smtp.mailfrom=honor.com; arc=none smtp.client-ip=81.70.206.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=honor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=honor.com Received: from w001.hihonor.com (unknown [10.68.25.235]) by mta20.hihonor.com (SkyGuard) with ESMTPS id 4dmx8V1Q55zYkynt; Thu, 8 Jan 2026 15:18:34 +0800 (CST) Received: from a006.hihonor.com (10.68.23.242) by w001.hihonor.com (10.68.25.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.27; Thu, 8 Jan 2026 15:21:19 +0800 Received: from a011.hihonor.com (10.68.31.243) by a006.hihonor.com (10.68.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.27; Thu, 8 Jan 2026 15:21:18 +0800 Received: from a011.hihonor.com ([fe80::2ded:f949:6f48:faf]) by a011.hihonor.com ([fe80::2ded:f949:6f48:faf%7]) with mapi id 15.02.2562.027; Thu, 8 Jan 2026 15:21:18 +0800 From: wangtao To: "mingo@redhat.com" , "peterz@infradead.org" , "juri.lelli@redhat.com" , "vincent.guittot@linaro.org" CC: "dietmar.eggemann@arm.com" , "rostedt@goodmis.org" , "bsegall@google.com" , "mgorman@suse.de" , "vschneid@redhat.com" , "linux-kernel@vger.kernel.org" , liulu 00013167 , "wangbintian(BintianWang)" , wangzicheng Subject: RE: [PATCH v5] sched/fair: Add fair placement lag Thread-Topic: [PATCH v5] sched/fair: Add fair placement lag Thread-Index: AQHccymIOfNPjrGrkE6mYeVUIGBK47VH8OCA Date: Thu, 8 Jan 2026 07:21:18 +0000 Message-ID: References: <20251222095700.6598-1-tao.wangtao@honor.com> In-Reply-To: <20251222095700.6598-1-tao.wangtao@honor.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi, Just a gentle ping on the patch I sent about two weeks ago. https://lore.kernel.org/all/20251222095700.6598-1-tao.wangtao@honor.com/ The patch targets question (2) in Section 4 "Fairness in Dynamic Systems" of the EEVDF paper: "When a client with non-zero lag leaves the competition, what should be its lag when it rejoins the competition?" Section 5 of the paper notes that there is no single clearly fair way to handle this, and therefore presents three implementation strategies (Strategy #1, #2, and #3) with different trade-offs. The current Linux EEVDF implementation corresponds to Strategy #1. The patch introduces FAIR_PLACE_LAG, which keeps V + J invariant when there are runnable tasks, and aims to avoid the "V moving backwards" and order-instability issues in the T1/T2/T3 example, providing more stable and arguably fairer behavior when entities frequently leave and rejoin. Hackbench results in the commit message show some improvements. Could you please take a look and let me know whether the overall direction looks acceptable, and if exposing FAIR_PLACE_LAG as an optional alternative to the existing Strategy #1 would be reasonable? I'm happy to rework and send a new version if needed. Thanks for your time. Best regards, Tao