> > '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?
Aaaargh, you are absolutely right! My fault, I was blinded by looking at the sched_proc_to_cpu_cost() in sched_choosecpu(), where the ci changes while iterating on the cpus, and mentally transferred that to sched_steal_proc(). > > 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) My apologies, I will base it on facts and testing. :( Thanks
