On 04/02/20(Tue) 13:13, Amit Kulkarni wrote: > [...] > 'ci' changes after we proceed to another cpu, and cost will be different for > each cpu+proc combination.
Look at at line 516 of kern/kern_sched.c doest the first argument of sched_proc_to_cpu_cost() change? > Actually, in the steal case, if there is a large difference in > spc_curpriority and p_usrpri between running proc which is SONPROC vs the > current proc, then the cost will be skewed towards an outlier, but this will > happen for all procs for that ci as you analyzed. You missed the point above, the CPU is trying to steal a thread because it has nothing to execute, so no SONPROC. > To summarize: currently, if a cpu is running 1-2 procs with large differences > in priority, there is a high possibility that this function will go steal a > proc from it for the just idled cpu. Whereas at the same time, another cpu is > running 5-7 procs with exact same priorities, that will be ignored in the > above calculation! We should have stolen from the cpu with 5-7 procs. Is it speculation based on your understanding of what you read or can you reproduce this? > I hope this is a correct interpretation? Is there something wrong in this > analysis? Why do you ask? Are you interested in changing the actual code? If so why? Are you interested in understanding what does it do? > Another small optimization is [...] How do you know it's an optimization? How did you test it? What is your workload? How did you prove your reasoning? I don't know why you're sending such emails, but if your goal is to contribute may I suggest you to pick a simpler place to start and to really understand it before sending diffs? Maybe test your changes, gather data, look at facts instead of guesses... :o)
