From: Tim Leslie Subject: Re: Move p_estcpu accumulation from schedclock to tuagg_add_runtime To: Claudio Jeker Cc: "tech@openbsd.org" Date: Thu, 05 Feb 2026 11:11:35 +0000 > > Currently p_estcpu is incremented in schedclock() under SCHED_LOCK for the running process. This moves the accumulation to tuagg_add_runtime(), which is called on every context switch to track per-thread runtime. > > > What happens if there is no context switch? Right now the priority of the > process goes up on every schedclock() run and so another process sitting > on the run queue will force a context switch at some point. > > E.g. something like md5 -tttttttt tends to hog a cpu since there is > nothing going on that would force a context switch. The same thing that happens now. Current code bases pre-empt decisions on the priority value fed to setrunqueue, which is set to spc->spc_curpriority in userret. The only other time this field is changed is in sleep_setup. So the base priority at which a process is running at is fixed when it goes ONPROC. So your piggy of an md5 process will sit there, tick up its estcpu until 1) something comes along that has a sufficiently higher prio and triggers a pre-empt (a timer, another process, whatever), 2) roundrobin hits its second tick (so somewhere between 100-200ms depending on when in the tick it started), and 3) it decides to yield for whatever reason. At current, schedclock will, every 10ms, faithfully tick up the ONPROC proc's estcpu (until it hits the relevant estcpu cap), and updates the usrpri. But no pre-empt comparison values will change. All the processes waiting in line will tick down their estcpu slowly in schedcpu's once a second check, which might change their priority sufficiently to change queue buckets, and if so AND their priority is higher than the running process was at enqueue, then THAT will trigger a pre-empt. We only really need to degradation to happen in one direction - either those in line get progressively more important, or the one on the process progressively less important. Current logic does only the first. Most other OS's only do the first (deadline schedulers will all have deadlines that are closer over time, etc.). My patch changes when we do the estcpu math, but does not affect the underlying decision logic. Tim