> Date: Tue, 29 Aug 2023 19:15:14 +0200 > From: Claudio Jeker <clau...@openbsd.org> > > On Tue, Aug 29, 2023 at 01:01:10AM +0000, Eric Wong wrote: > > >Synopsis: RLIMIT_CPU doesn't work reliably on mostly idle systems > > >Category: system > > >Environment: > > System : OpenBSD 7.3 > > Details : OpenBSD 7.3 (GENERIC.MP) #1242: Sat Mar 25 18:04:31 MDT > > 2023 > > > > dera...@octeon.openbsd.org:/usr/src/sys/arch/octeon/compile/GENERIC.MP > > > > Architecture: OpenBSD.octeon > > Machine : octeon > > >Description: > > > > RLIMIT_CPU doesn't work reliably when few/no syscalls are made on an > > otherwise idle system (aside from the test process using up CPU). > > It can take 20-50s to fire SIGKILL with rlim_max=9 (and the SIGXCPU > > from rlim_cur=1 won't even fire). > > > > I can reproduce this on a private amd64 VM and also on gcc231 > > on GCC compiler farm <https://cfarm.tetaneutral.net/>. > > I can't reproduce this on a busy system like gcc220 on cfarm, > > however. > > Thanks for the report. There is indeed an issue in how the CPU time is > accounted on an idle system. The below diff is a possible fix. > > In roundrobin() force a resched and therefor mi_switch() when > SPCF_SHOULDYIELD is set. On an idle CPU mi_switch() will just do all > accounting bits but skip the expensive cpu_switchto() since the proc > remains the same.
A bit of a hack, but probably better than trying to account for spc_runtime at the point where we check the limit. Also this will call smr_idle() sooner, which may help speed up smr? ok kettenis@ > Index: kern/sched_bsd.c > =================================================================== > RCS file: /cvs/src/sys/kern/sched_bsd.c,v > retrieving revision 1.84 > diff -u -p -r1.84 sched_bsd.c > --- kern/sched_bsd.c 29 Aug 2023 16:19:34 -0000 1.84 > +++ kern/sched_bsd.c 29 Aug 2023 16:20:03 -0000 > @@ -106,7 +106,7 @@ roundrobin(struct clockintr *cl, void *c > } > } > > - if (spc->spc_nrun) > + if (spc->spc_nrun || spc->spc_schedflags & SPCF_SHOULDYIELD) > need_resched(ci); > } > > >
