Re: [PATCH V3 1/2] sched: Reduce the default slice to avoid tasks getting an extra tick

[zihan zhou]

> 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!