From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 D342835CBD1 for ; Mon, 2 Feb 2026 11:23:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770031394; cv=none; b=f6YUMs8mBMOQxHPWcTl+IgIQLkX6nDXpFOjkoIg+h887rl6kkWMqo9H31PI8kWhMM7h0AevJC4gj6DNTiwcYLTnyYF4H0Ehl5sehhu7gdTpy74CStx2B0macA/e12x3rx1laxYcSAt77OaNBXdRnMZi47Vi/8nT5iLPABkVjHUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770031394; c=relaxed/simple; bh=ARsT4lM9Dzzw/W5zOImBTUByZ7K05rL2JmltfctHkd8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=e6KcFHwcExvzHLPqlnbVjzCoFcL/W0ecS/SWQBJszYiN4eqLINv10Nt6KsUq7OMHYh3dwg620PEpztnF+uxdsvktLDmtJE1wAGeHdI7cHSrLysox1YaIz2cXtWSxBJ2SFXKUMeBzYp21qtw94IAFBsG2QOBC1WSCvSA5TUYllR8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=oMVD2NwV; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="oMVD2NwV" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=pyV4fFSwT8V3UnTryQamPhShMJyrnDAkeL1TCK/5zwA=; b=oMVD2NwVwyUNXTaQ3Yx/qbb2sEmaDJ2ethI01iZEx19601WQZ6bmKpufJ8hLXuyvmF52r9Bcj wr+K1rZgVXE4aKX2k87RlF15UihXHI4Nu27/Zadwzl2Rx5LmF6fxImMe6jqGfbcRroSsFkelcJ1 VVxwXN7yXil0fw0zxy6FvsQ= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4f4PHz5Dk1z1K96Y; Mon, 2 Feb 2026 19:18:39 +0800 (CST) Received: from dggpemf100017.china.huawei.com (unknown [7.185.36.74]) by mail.maildlp.com (Postfix) with ESMTPS id 5CDF74056C; Mon, 2 Feb 2026 19:23:10 +0800 (CST) Received: from [10.67.111.186] (10.67.111.186) by dggpemf100017.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 2 Feb 2026 19:23:09 +0800 Message-ID: <378ef85d-3578-156d-6b60-dd22bfe0129a@huawei.com> Date: Mon, 2 Feb 2026 19:23:08 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [PATCH 4/4] sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") To: Peter Zijlstra CC: , , , , , , , , , , , , , , Hui Tang References: <20260130093439.803225718@infradead.org> <20260130094608.304041157@infradead.org> <716f3b5a-8a82-88e1-b684-4723882a0d6b@huawei.com> <20260131152135.GA509491@noisy.programming.kicks-ass.net> <20260202091234.GA1395416@noisy.programming.kicks-ass.net> From: Zhang Qiao In-Reply-To: <20260202091234.GA1395416@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To dggpemf100017.china.huawei.com (7.185.36.74) 在 2026/2/2 17:12, Peter Zijlstra 写道: > On Sat, Jan 31, 2026 at 04:21:39PM +0100, Peter Zijlstra wrote: >> On Sat, Jan 31, 2026 at 09:47:07AM +0800, Zhang Qiao wrote: >> >>>> if (se->on_rq) { >>>> /* commit outstanding execution time */ >>>> update_curr(cfs_rq); >>>> - update_entity_lag(cfs_rq, se); >>>> - se->deadline -= se->vruntime; >>>> + avruntime = avg_vruntime(cfs_rq); >>>> + se->vlag = entity_lag(avruntime, se); >>> >>> >>> vlag is updated here. Considering vlag and vprot share the same union, updating >>> vlag will overwrite vprot. Is it right to call protect_slice() (which use vprot) >>> after this update? >> >> Oh you are quite right; I'm sure Ingo had a patch removing that union, >> but clearly that's not been merged yet. >> >> Sorry about that mistake; I'll make a new version on Monday. > > After looking at things, I think the best option is to simply remove > that union. > Agreed. The union makes the code logic overly complex and error-prone. > The thing is, I can fix reweight to respect this union, but there are > more problems, notably the sched_change pattern will not only call > put_prev_task/set_next_task, it will actually dequeue/enqueue the thing > and therefore 'temporarily' use the vlag field, destroying the vprot > value. > > And yes, we can fix all that, but I'm thinking that at that point the > union is more trouble than its worth. > > > . >