[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250222031945.67519-1-15645113830zzh@gmail.com>
Date: Sat, 22 Feb 2025 11:19:46 +0800
From: zihan zhou <15645113830zzh@...il.com>
To: qyousef@...alina.io
Cc: 15645113830zzh@...il.com,
bsegall@...gle.com,
dietmar.eggemann@....com,
juri.lelli@...hat.com,
linux-kernel@...r.kernel.org,
mgorman@...e.de,
mingo@...hat.com,
peterz@...radead.org,
rostedt@...dmis.org,
vincent.guittot@...aro.org,
vschneid@...hat.com
Subject: Re: [PATCH V3 1/2] sched: Reduce the default slice to avoid tasks getting an extra tick
> Yes. The minimum bar of modern hardware is higher now. And generally IMHO this
> value depends on workload. NR_CPUs can make an overloaded case harder, but it
> really wouldn't take much to saturate 8 CPUs compared to 2 CPUs. And from
> experience the larger the machine the larger the workload, so the worst case
> scenario of having to slice won't be in practice too much different. Especially
> many programmers look at NR_CPUs and spawn as many threads..
>
> Besides with EAS we force packing, so we artificially force contention to save
> power.
>
> Dynamically depending on rq->hr_nr_runnable looks attractive but I think this
> is a recipe for more confusion. We sort of had this with sched_period, the new
> fixed model is better IMHO.
Hi, It seems that I have been thinking less about things. I have been re
reading these emails recently. Can you give me the LPC links for these
discussions? I want to relearn this part seriously, such as why we don't
dynamically adjust the slice.
Thanks!
Powered by blists - more mailing lists