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.b...@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. >
