[PATCH] um: insert scheduler ticks when userspace does not yield

[Benjamin Berg]

Hi,

On Thu, 2024-09-19 at 16:11 +0200, Benjamin Beichler wrote:
> Could this also eliminate/address the busy-loop hack in timer_read in
> time.c?

Hmm, I was considering changing the other hack in handle_syscall to
also use this approach.

But, I don't think the timer_read hack can be removed. In the case of
userspace reading the time, it should not see the difference of the
sched_clock. So even though the process would start use CPU time, the
realtime clock should not change and python would continue to busyloop.

> And another question: Why you remove only 1 extra jiffy in the timer 
> callbacks and not all the extra jiffies? Is there always only 1 or
> could there be multiple?

Oh, there we can absolutely end up inserting multiple jiffies. However,
deliver_alarm will cause "jiffies" to be incremented by one. So by
subtracting only one jiffie we can avoid a situation where sched_clock
moves backwards.

Benjamin

> 
> regards
> 
> Benjamin Beichler
> 
> Am 13.09.2024 um 22:17 schrieb Benjamin Berg:
> > From: Benjamin Berg <benjamin.berg at intel.com>
> > 
> > In time-travel mode userspace can do a lot of work without any time
> > passing. Unfortunately, this can result in OOM situations as the
> > RCU
> > core code will never be run.
> > 
> > Work around this by keeping track of userspace processes that do
> > not
> > yield for a lot of operations. When this happens, insert a jiffie
> > into
> > the sched_clock clock to account time against the process and cause
> > the
> > bookkeeping to run.
> > 
> > As sched_clock is used for tracing, it is useful to keep it in sync
> > between the different VMs. As such, try to remove added ticks again
> > when
> > the actual clock ticks.
>