From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from r3-23.sinamail.sina.com.cn (r3-23.sinamail.sina.com.cn [202.108.3.23]) (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 26B02307AF7 for ; Thu, 4 Dec 2025 06:59:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.23 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764831599; cv=none; b=cQKSv0JH+cmblfFYX9cbDEw7WcCGN0JQbbVAMefL0quXGGOVlRe9z/rSWffKUa0d+Balu0fjXoSMaGRJH/lksiAUoXGOKlj0m9luj1cvKbdDB3YgibRVYM53JSpCQy8UWFreEXnEb7VCkZtKvvTlFVGjDdn2bvsCNb9vR2nED14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764831599; c=relaxed/simple; bh=Cf2rF7a7HYRuMS5pDuOUzyQ+k8oMQlTNW+lChOKVv18=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sE1KY+xBWzG/F+PQ2yQWob7N0ac2m0erZ/GUj8ZLKJcdzghvBsrlzrh7LIHpweJoVy6xBtN14uLNjnxApkWPamwz8VC+MCDrDI8siyDzvG00tcXEwE5VTrpTkqqe7D47t9aYau0Xa1gw5B+ixq7X8IJ6Vxhq0qeeOqoR0ZLzgIE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=kNO5tNDH; arc=none smtp.client-ip=202.108.3.23 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="kNO5tNDH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1764831594; bh=Tr5fPHy4+2psBcO9MjwuuXy0Z+aAJTUNg2lDPO/kMPc=; h=From:Subject:Date:Message-ID; b=kNO5tNDHWngVd2gRW9dqoxCL4y6+GA0RXmwSzvqQwgmdYro6oXmhUoyS+K6JZ0gBX YYsHdBSReJ5gB0o8qJbJopzsqfg9uaQqfZYmTt0ABrkHhlhYGA0Sl9CUnC6qHbGspB hAOxg6TbOVxyVjxWz10V7QQiG1UmC8jc8fE219v0= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.57.85]) by sina.com (10.54.253.31) with ESMTP id 6931316400001BF7; Thu, 4 Dec 2025 14:59:51 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 2486086816205 X-SMAIL-UIID: 7B478B97689E4C7FA6ADC106E5E1587F-20251204-145951-1 From: Hillf Danton To: Vincent Guittot Cc: peterz@infradead.org, linux-kernel@vger.kernel.org, pierre.gondois@arm.com, kprateek.nayak@amd.com, qyousef@layalina.io, christian.loehle@arm.com, luis.machado@arm.com Subject: Re: [RFC PATCH 6/6 v7] sched/fair: Add EAS and idle cpu push trigger Date: Thu, 4 Dec 2025 14:59:39 +0800 Message-ID: <20251204065941.1829-1-hdanton@sina.com> In-Reply-To: References: <20251201091308.761711-1-vincent.guittot@linaro.org> <20251201091308.761711-7-vincent.guittot@linaro.org> <20251202094454.9608-1-hdanton@sina.com> <20251203090042.1804-1-hdanton@sina.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="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 3 Dec 2025 14:32:06 +0100 Vincent Guittot wrote: > On Wed, 3 Dec 2025 at 10:00, Hillf Danton wrote: > > Given task queued on rq, I find the correct phrase, stack, in the cover > > letter instead of stuck, and the long-standing stacking tasks mean load > > balancer fails to cure that stack. 1/7 fixes that failure, no? > > It's not just stacked because we sometimes/often want to stack tasks > on the same CPU. EAS is based on the assumption that tasks will sleep > and wake up regularly and EAS will select a new CPU at each wakeup but > it's not always true. We can have situations where task A has been put > on CPU0when waking up, sharing the CPU with others tasks. But after > some time, task A should be better on CPUB now not because of not > fitting anymore on CPU0 but just because the system state has changed > since its wakeup. Because task A shares the CPU0 with other tasks, it > can takes dozen/hundreds of ms to finish its works and to sleep and we > don't wait those hundreds of ms whereas a CPU1 might be a better > choice now. > Even if task is pushed from an ARM little core to a big one, the net result could be zero, either because the number of stacking tasks on the dst CPU increases or more important the dst CPU cycles are shared at the pace of tick. In general if stacking is not mitigated but migrated from one CPU to another, pushing could not make much difference.