Received-SPF: pass (google.com: domain of linux-kernel+bounces-1798-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 12 Dec 2023 15:59:16 +0000
From: Qais Yousef <qyousef@layalina.io>
To: Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] sched/fair: Check a task has a fitting cpu when
 updating misfit
Message-ID: <20231212155916.cqlgv5eypuvfom3n@airbuntu>
References: <20231212154056.626978-1-qyousef@layalina.io>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20231212154056.626978-1-qyousef@layalina.io>

On 12/12/23 15:40, Qais Yousef wrote:

> Food for thoughts: should misfit cause balance_interval to double? This patch
> will still be needed if the answer is yes to avoid unnecessary misfit-lb to
> trigger repeatedly anyway.

I should add, should balance_interval be capped to smaller values? Anything
above 64ms looks too high to me, even 64ms for systems that need responsiveness
can be considered too high. 16ms or 32ms look more reasonable to my (likely
very) naive eyes :-)

We should probably look at reducing TICK value as well. 1ms requires 3 failures
to reach 8ms for example. But 4ms TICK requires one failure to go to 8ms. Maybe
there's room to make the doubling logic more normalized. 3 failures on 4ms will
reach 32ms.


Cheers

--
Qais Yousef