On Tue, Jan 28, 2020 at 09:08:37PM +0800, Hillf Danton wrote: > > Functionally it works, it's just slow. There is a cost to migration and > > a cost to exiting from idle state and ramping up the CPU frequency. > > > Yeah we need to pay some costs but are not they compensated by the ping > and pong that waker and wakee are happy to play for ten minutes on > different cpus sharing cache if you have no way to migrate waker? > I could get into it depth but the changelog already mentions the cpufreq implications and the consequences of round-robining around the machine as a side-effect of how select_idle_sibling works. The data indicates that we are not compensated by the migrations. > Or back to the kworker case, a tradeoff needs to make between making kworker > able to run on cache-sharing cpus and adding scheduling heuristics. IOW > is cache affinity the key to the problem? > The kworker is already running on CPUs sharing cache. That is not the central issue. -- Mel Gorman SUSE Labs
