Messages in this thread | | | From | Anna-Maria Behnsen <> | Subject | Re: [PATCH v8 00/25] timer: Move from a push remote at enqueue to a pull at expiry model | Date | Thu, 19 Oct 2023 16:14:36 +0200 |
| |
Hello Prateek,
I'm sorry for the late reply!
K Prateek Nayak <kprateek.nayak@amd.com> writes:
> Hello Anna-Maria, > > On 10/4/2023 6:04 PM, Anna-Maria Behnsen wrote: >> [..snip..] >> >> Ping Pong Oberservation >> ^^^^^^^^^^^^^^^^^^^^^^^ >> >> During testing on a mostly idle machine a ping pong game could be observed: >> a process_timeout timer is expired remotely on a non idle CPU. Then the CPU >> where the schedule_timeout() was executed to enqueue the timer comes out of >> idle and restarts the timer using schedule_timeout() and goes back to idle >> again. This is due to the fair scheduler which tries to keep the task on >> the CPU which it previously executed on. > > Regarding above, are you referring to "wake_up_process(timeout->task)" in > "process_timeout()" ends up waking the task on an idle CPU instead of the > CPU where process_timeout() ran?
Yes.
> In which case, have you tried using the "WF_CURRENT_CPU" flag for the > wakeup? (landed upstream in v6.6-rc1) It is only used by wait queues in > kernel/sched/wait.c currently but perhaps we can have a > "wake_up_process_on_current_cpu()" that process_timeout() can call. > > Something along the lines of: > > int wake_up_process_on_current_cpu(struct task_struct *p) > { > return try_to_wake_up(p, TASK_NORMAL, WF_CURRENT_CPU); > } > EXPORT_SYMBOL(wake_up_process_on_current_cpu); > > Thoughts?
I didn't look into this again. Back than, I reported the observation to scheduler people (others also already observed this behavior). I'm not so familiar with scheduling, so I will ping scheduler people to give you a feedback.
Thanks,
Anna-Maria
| |