Messages in this thread | | | From | John Stultz <> | Date | Mon, 17 Oct 2022 20:59:00 -0700 | Subject | Re: [PATCH RFC v4 2/3] sched: Avoid placing RT threads on cores handling long softirqs |
| |
On Mon, Oct 17, 2022 at 8:42 PM John Stultz <jstultz@google.com> wrote: > On Mon, Oct 17, 2022 at 5:40 AM Alexander Gordeev > <agordeev@linux.ibm.com> wrote: > > select_task_rq_rt() takes the lock and reads curr already, > > before calling this funciton. I think there is a way to > > decompose it in a better way. > > Hrm. Suggestions? As select_task_rq_rt() is only one of the callers. > Trying to pass curr into cpu_busy_with_softirqs() would mean > cpupri_find_fitness() would need to read the cpu_rq(cpu)->curr for the > specified cpu and pass that in. > > The original patch actually was >
Whoops I didn't finish my thought there. I was going to say the original patch did similar to your suggestion, passing the target cpu curr task value in from select_task_rq_rt(). However it didn't use the cpupri_find_fitness() and duplicated a lot of similar logic in a way that is not as nice as what the current version uses. But I'm very much open to suggestions for other ways to simplify that as you suggest.
thanks -john
| |