sys/sched.h: conceal schedstate_percpu definition from userspace

2023-10-29 Thread Scott Cheloha
struct schedstate_percpu contains clockintr pointers. struct clockintr is not defined int userspace, so we need to conceal the schedstate_percpu definition from userspace. Nothing in base userspace currently uses the struct. I think we should leave in place for now. Something might depend

Re: bt(5), btrace(8): execute END probe and print maps after exit() statement

2023-10-21 Thread Scott Cheloha
On Sat, Oct 21, 2023 at 07:17:05PM +0200, Martin Pieuchot wrote: > On 18/10/23(Wed) 12:56, Scott Cheloha wrote: > > Hi, > > > > A bt(5) exit() statement causes the btrace(8) interpreter to exit(3) > > immediately. > > > > A BPFtrace exit() statement is

bt(5), btrace(8): execute END probe and print maps after exit() statement

2023-10-18 Thread Scott Cheloha
Hi, A bt(5) exit() statement causes the btrace(8) interpreter to exit(3) immediately. A BPFtrace exit() statement is more nuanced: the END probe is executed and the contents of all maps are printed before the interpreter exits. This patch adds a halting check after the execution of each bt(5)

Re: timeout(1): align execvp(3) failure statuses with GNU timeout

2023-10-16 Thread Scott Cheloha
On Sun, Oct 15, 2023 at 01:48:13PM -0600, Todd C. Miller wrote: > On Sun, 15 Oct 2023 13:53:46 -0500, Scott Cheloha wrote: > > > Align timeout(1)'s execvp(3) failure statuses with those of GNU > > timeout. 127 for ENOENT, 126 for everything else. > > Looks correct

timeout(1): align execvp(3) failure statuses with GNU timeout

2023-10-15 Thread Scott Cheloha
Align timeout(1)'s execvp(3) failure statuses with those of GNU timeout. 127 for ENOENT, 126 for everything else. $ cd /tmp $ touch script.sh $ ls -l script.sh -rw-r--r-- 1 ssc wheel 0 Oct 15 13:43 script.sh $ gtimeout 1.0 ./script.sh ; echo $? gtimeout: failed to run command './script.sh':

Re: tcp syn cache unlock

2023-10-11 Thread Scott Cheloha
On Tue, Oct 10, 2023 at 05:26:14PM +0300, Vitaliy Makkoveev wrote: > On Tue, Oct 10, 2023 at 09:06:23AM -0500, Scott Cheloha wrote: > > On Fri, Oct 06, 2023 at 03:41:39PM +0200, Alexander Bluhm wrote: > > > On Fri, Oct 06, 2023 at 03:47:31PM +0300, Vitaliy Makkoveev wrote: >

bt(5), btrace(8): support modulo operator ('%')

2023-10-10 Thread Scott Cheloha
This adds support for the modulo operator to btrace(8). I was trying to use it like this: $start = nsecs; /* ... */ $elapsed = nsecs - $start; printf("%d.%09d seconds\n", $elapsed / 10, $elapsed % 10); and noticed it was missing. ok?

Re: tcp syn cache unlock

2023-10-10 Thread Scott Cheloha
On Fri, Oct 06, 2023 at 03:41:39PM +0200, Alexander Bluhm wrote: > On Fri, Oct 06, 2023 at 03:47:31PM +0300, Vitaliy Makkoveev wrote: > > On Fri, Oct 06, 2023 at 02:14:52PM +0200, Alexander Bluhm wrote: > > > > @@ -718,11 +743,13 @@ softclock(void *arg) > > > >

Re: tcp syn cache unlock

2023-10-05 Thread Scott Cheloha
On Thu, Oct 05, 2023 at 12:57:24AM +0200, Alexander Bluhm wrote: > > This is a first step to unlock TCP syn cache. The timer function > is independent of the socket code. That makes it easy to start > there. > > [...] > > Still missing: > - [...] > - Run timer without kernel lock. I am not

Re: dt(4), hardclock(9): move interval, profile providers to dedicated callback

2023-09-17 Thread Scott Cheloha
08/23(Fri) 21:00, Scott Cheloha wrote: > > On Thu, Aug 24, 2023 at 07:21:29PM +0200, Martin Pieuchot wrote: > > > [...] > > > The only behavior that needs to be preserved is the output of dumping > > > stacks. That means DT_FA_PROFILE and DT_FA_STATIC certainly ne

scheduler_start: move static timeout structs into callback functions

2023-09-16 Thread Scott Cheloha
The schedcpu() and loadavg() timeout structures are already hidden from the global namespace. We can further simplify scheduler_start() by moving the structures into the callback functions and statically initializing them with TIMEOUT_INITIALIZER(9). ok? Index: sched_bsd.c

ksh(1): implement p_tv() with p_ts()

2023-09-11 Thread Scott Cheloha
p_tv() is identical to p_ts() in every way except for the subsecond conversion constants. Better to write p_ts() once: in p_tv(), convert from timeval to timespec and call p_ts(). ok? Index: c_sh.c === RCS file:

clockintr: replace CL_RNDSTAT with global variable "statclock_is_randomized"

2023-09-09 Thread Scott Cheloha
I'm going to break the big statclock() patch on tech@ into smaller chunks that are easier to review. The goal here is to move control of statclock() out of the clock interrupt subsystem and transform it into a client of that subsystem. I think we can do this in four parts. Part 3 is the most

kernel: remove schedhz

2023-09-08 Thread Scott Cheloha
mpi@ notes that alpha doesn't set schedhz anymore, so schedhz is always zero and serves no purpose. We could remove it (patch below). Or we could wait a bit to see if schedclock() finds a future as an independent clock interrupt. My guess is that roundrobin() (or something like it) will have a

Re: Use counters_read(9) from ddb(4)

2023-09-06 Thread Scott Cheloha
On Wed, Sep 06, 2023 at 01:04:19PM +0100, Martin Pieuchot wrote: > Debugging OOM is hard. UVM uses per-CPU counters and sadly > counters_read(9) needs to allocate memory. This is not acceptable in > ddb(4). As a result I cannot see the content of UVM counters in OOM > situations. > > Diff

clockintr: add clockintr_advance_random()

2023-09-05 Thread Scott Cheloha
mpi@ suggests folding the pseudorandom advance code from clockintr_statclock() into the clockintr API itself. This replaces three API calls -- clockintr_expiration(), clockintr_nsecuptime(), and clockintr_schedule() -- we just one call to a new function, clockintr_advance_random(). I'm fine with

Re: clockintr: move control of statclock() into scheduler

2023-09-04 Thread Scott Cheloha
On Thu, Aug 31, 2023 at 04:01:35PM -0500, Scott Cheloha wrote: > This is the next patch in the clock interrupt policy reorganization > series. > > While the hardclock/dt(4) patch is being rewritten we can do this > orthogonal statclock() patch. It needs to get done at some poin

clockintr: move control of statclock() into scheduler

2023-08-31 Thread Scott Cheloha
This is the next patch in the clock interrupt policy reorganization series. While the hardclock/dt(4) patch is being rewritten we can do this orthogonal statclock() patch. It needs to get done at some point anyway, may as well do it now. So, this patch moves most of the statclock() code out of

sched_cpu_init: no need to NULL-check clockintr pointers

2023-08-31 Thread Scott Cheloha
We don't actually need these NULL-checks, my mistake. sched_init_cpu() is only ever run once for a given cpu_info. ok? Index: kern_sched.c === RCS file: /cvs/src/sys/kern/kern_sched.c,v retrieving revision 1.87 diff -u -p -r1.87

Re: dt(4), hardclock(9): move interval, profile providers to dedicated callback

2023-08-25 Thread Scott Cheloha
On Thu, Aug 24, 2023 at 07:21:29PM +0200, Martin Pieuchot wrote: > On 23/08/23(Wed) 18:52, Scott Cheloha wrote: > > This is the next patch in the clock interrupt reorganization series. > > Thanks for your diff. I'm sorry but it is really hard for me to help > review

dt(4), hardclock(9): move interval, profile providers to dedicated callback

2023-08-23 Thread Scott Cheloha
This is the next patch in the clock interrupt reorganization series. This patch moves the entry points for the interval and profile dt(4) providers from the hardclock(9) to a dedicated clock interrupt callback, dt_prov_profile_intr(), in dev/dt/dt_prov_profile.c. - To preserve current behavior,

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-21 Thread Scott Cheloha
On Tue, Aug 22, 2023 at 11:28:25AM +0800, Kevin Lo wrote: > On Mon, Aug 21, 2023 at 09:53:53PM -0500, Scott Cheloha wrote: > > On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > > > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > > >

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-21 Thread Scott Cheloha
On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > >

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-21 Thread Scott Cheloha
On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > >

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-21 Thread Scott Cheloha
On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > > This is the next patch in the clock interrupt reorganization series. > > &g

i386: i8254_initclocks: set IPL_MPSAFE for clock, rtc IRQs

2023-08-20 Thread Scott Cheloha
pOn amd64 we lie about the interrupts established during i8254_initclocks(). We claim they are MP-safe in order to mollify a KASSERT in intr_establish() and continue booting. See amd64/isa/clock.c: 279 void 280 i8254_initclocks(void) 281 { 282 i8254_inittimecounter();

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-19 Thread Scott Cheloha
On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > This is the next patch in the clock interrupt reorganization series. > > Before we continue breaking up the hardclock(9) we need to detour into > the MD code. > > This patch divides the "initialization&q

all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-13 Thread Scott Cheloha
This is the next patch in the clock interrupt reorganization series. Before we continue breaking up the hardclock(9) we need to detour into the MD code. This patch divides the "initialization" parts of cpu_initclocks() from the "start the clock interrupt" parts. Seprating the two parts leaves

Re: hardclock(9), roundrobin: make roundrobin() an independent clock interrupt

2023-08-10 Thread Scott Cheloha
On Thu, Aug 10, 2023 at 07:32:05PM +0200, Martin Pieuchot wrote: > On 10/08/23(Thu) 12:18, Scott Cheloha wrote: > > On Thu, Aug 10, 2023 at 01:05:27PM +0200, Martin Pieuchot wrote: > > [...] > > > Can we get rid of `hardclock_period' and use a variable set to 100ms? >

Re: agtimer(4/arm64): simplify agtimer_delay()

2023-08-10 Thread Scott Cheloha
On Tue, Aug 08, 2023 at 08:00:47PM +0200, Mark Kettenis wrote: > > From: Dale Rahn > > Date: Tue, 8 Aug 2023 12:36:45 -0400 > > > > Switching the computation of cycles/delaycnt to a proper 64 value math > > instead of the '32 bit safe' complex math is likely a good idea. > > However I am not

Re: hardclock(9), roundrobin: make roundrobin() an independent clock interrupt

2023-08-10 Thread Scott Cheloha
On Thu, Aug 10, 2023 at 01:05:27PM +0200, Martin Pieuchot wrote: > On 05/08/23(Sat) 17:17, Scott Cheloha wrote: > > This is the next piece of the clock interrupt reorganization patch > > series. > > The round robin logic is here to make sure process doesn't hog a CPU.

Re: EVFILT_TIMER add support for different timer precisions NOTE_{,U,N,M}SECONDS

2023-08-08 Thread Scott Cheloha
On Sat, Aug 05, 2023 at 01:33:05AM -0400, A Tammy wrote: > > On 8/5/23 00:49, Scott Cheloha wrote: > > On Sat, Aug 05, 2023 at 12:17:48AM -0400, aisha wrote: > >> On 22/09/10 01:53PM, Visa Hankala wrote: > >>> On Wed, Aug 31, 2022 at 04:48:37PM -0400, aisha wrote

agtimer(4/arm64): simplify agtimer_delay()

2023-08-07 Thread Scott Cheloha
The agtimer(4/arm64) delay(9) implementation is quite complicated. This patch simplifies it. Am I missing something here? There's no reason to implement the busy-loop like this, right? ok? Index: agtimer.c === RCS file:

hardclock(9), roundrobin: make roundrobin() an independent clock interrupt

2023-08-05 Thread Scott Cheloha
This is the next piece of the clock interrupt reorganization patch series. This patch removes the roundrobin() call from hardclock() and makes roundrobin() an independent clock interrupt. - Revise roundrobin() to make it a valid clock interrupt callback. It remains periodic. It still runs at

Re: EVFILT_TIMER add support for different timer precisions NOTE_{,U,N,M}SECONDS

2023-08-04 Thread Scott Cheloha
On Sat, Aug 05, 2023 at 12:17:48AM -0400, aisha wrote: > On 22/09/10 01:53PM, Visa Hankala wrote: > > On Wed, Aug 31, 2022 at 04:48:37PM -0400, aisha wrote: > > > I've added a patch which adds support for NOTE_{,U,M,N}SECONDS for > > > EVFILT_TIMER in the kqueue interface. > > > > It sort of

Re: uvm_loadav: don't recompute schedstate_percpu.spc_nrun

2023-08-03 Thread Scott Cheloha
On Thu, Aug 03, 2023 at 09:09:30AM -0600, Theo de Raadt wrote: > Scott Cheloha wrote: > > > > > How about this. Kill the spc_ldavg calculation. Its use is more then > > > > questionable. The cpu selection code using this is not wroking well and > > &

Re: uvm_loadav: don't recompute schedstate_percpu.spc_nrun

2023-08-03 Thread Scott Cheloha
ot wrote: > > > > On 02/08/23(Wed) 14:22, Claudio Jeker wrote: > > > > > On Mon, Jul 31, 2023 at 10:21:11AM -0500, Scott Cheloha wrote: > > > > > > On Fri, Jul 28, 2023 at 07:36:41PM -0500, Scott Cheloha wrote: > > > > > > > claudio@ n

Re: hardclock: move setitimer(2) code into itimer_update()

2023-08-02 Thread Scott Cheloha
On Thu, Jul 27, 2023 at 10:45:50PM -0500, Scott Cheloha wrote: > On Wed, Jul 26, 2023 at 11:16:19AM -0500, Scott Cheloha wrote: > > This is the next patch in the clock interrupt reorganization series. > > > > Now that statclock() is cleaned up we

[v2]: uvm_meter, schedcpu: make uvm_meter() an independent timeout

2023-08-02 Thread Scott Cheloha
Now that the proc0 wakeup(9) is gone we can retry the other part of the uvm_meter() patch. uvm_meter() is meant to run every 5 seconds, but for historical reasons it is called from schedcpu() and it is scheduled against the UTC clock. schedcpu() and uvm_meter() have different periods, so

Re: uvm_meter: remove wakeup of proc0

2023-07-31 Thread Scott Cheloha
On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote: > On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote: > > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote: > > > This is the culprit: > > > > > > schedule_timeout_uninterruptible(long timeout) > > > { > >

Re: uvm_loadav: don't recompute schedstate_percpu.spc_nrun

2023-07-31 Thread Scott Cheloha
On Fri, Jul 28, 2023 at 07:36:41PM -0500, Scott Cheloha wrote: > claudio@ notes that uvm_loadav() pointlessly walks the allproc list to > recompute schedstate_percpu.spn_nrun for each CPU. > > We can just use the value instead of recomputing it. Whoops, off-by-one. The current lo

ualarm.3: cleanup, rewrites

2023-07-30 Thread Scott Cheloha
This patch drags ualarm.3 over to where alarm.3 is. I think it reads better and the wording is truer to what the function actually does. In particular, ualarm(3) does not block or "wait": the alarm is scheduled for asynchronous delivery by the operating system. I think I may have tried to clean

uvm_loadav: don't recompute schedstate_percpu.spc_nrun

2023-07-28 Thread Scott Cheloha
claudio@ notes that uvm_loadav() pointlessly walks the allproc list to recompute schedstate_percpu.spn_nrun for each CPU. We can just use the value instead of recomputing it. ok? Index: uvm_meter.c === RCS file:

Re: hardclock: move setitimer(2) code into itimer_update()

2023-07-27 Thread Scott Cheloha
On Wed, Jul 26, 2023 at 11:16:19AM -0500, Scott Cheloha wrote: > This is the next patch in the clock interrupt reorganization series. > > Now that statclock() is cleaned up we can turn to hardclock(). > > [...] > > This patch moves the setitimer(2) code out of hardclo

hardclock: move setitimer(2) code into itimer_update()

2023-07-26 Thread Scott Cheloha
This is the next patch in the clock interrupt reorganization series. Now that statclock() is cleaned up we can turn to hardclock(). The goal of the next four patches is to eliminate the need for the hardclock on secondary CPUs. Secondary CPUs don't need a hardclock. hardclock() is only used on

Re: option GPROF on riscv64

2023-07-22 Thread Scott Cheloha
On Fri, Jul 21, 2023 at 08:41:32PM +0200, Jeremie Courreges-Anglas wrote: > > Spotted while testing a diff from cheloha@, option GPROF doesn't build > on riscv64 because MCOUNT_ENTER/MCOUNT_EXIT from > riscv64/include/profile.h haven't been adapted for riscv64. > > riscv64

Re: [v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-21 Thread Scott Cheloha
On Fri, Jul 21, 2023 at 08:37:11PM +0200, Jeremie Courreges-Anglas wrote: > On Fri, Jul 21 2023, Mike Larkin wrote: > > On Fri, Jul 21, 2023 at 05:46:32PM +0200, Jeremie Courreges-Anglas wrote: > >> On Thu, Jul 20 2023, Scott Cheloha wrote: > >> > On Wed, Jul 19,

Re: [v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-20 Thread Scott Cheloha
On Thu, Jul 20, 2023 at 07:21:06PM +, Mike Larkin wrote: > On Thu, Jul 20, 2023 at 01:23:01PM -0500, Scott Cheloha wrote: > > On Wed, Jul 19, 2023 at 05:09:04AM +, Mike Larkin wrote: > > > On Tue, Jul 18, 2023 at 08:21:41AM -0500, Scott Cheloha wrote: > > > >

Re: [v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-20 Thread Scott Cheloha
On Wed, Jul 19, 2023 at 05:09:04AM +, Mike Larkin wrote: > On Tue, Jul 18, 2023 at 08:21:41AM -0500, Scott Cheloha wrote: > > This patch moves the profil(2)- and GPROF-specific parts of > > statclock() out into into separate clock interrupt routines. The > >

[v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-18 Thread Scott Cheloha
This patch moves the profil(2)- and GPROF-specific parts of statclock() out into into separate clock interrupt routines. The profil(2) part moves into profclock() and is enabled/disabled as needed during mi_switch(). The GPROF part moves into gmonclock() and is enabled/disabled as needed via

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-11 Thread Scott Cheloha
On Mon, Jul 10, 2023 at 10:41:15AM -0500, Scott Cheloha wrote: > On Mon, Jul 10, 2023 at 05:19:35PM +0200, Mark Kettenis wrote: > > > Date: Mon, 10 Jul 2023 09:57:39 -0500 > > > From: Scott Cheloha > > > > > > On Mon, Jul 10, 2023 at 07:42:55AM -0600,

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-10 Thread Scott Cheloha
On Mon, Jul 10, 2023 at 05:19:35PM +0200, Mark Kettenis wrote: > > Date: Mon, 10 Jul 2023 09:57:39 -0500 > > From: Scott Cheloha > > > > On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote: > > > I dare you to write the simplest fix for this, ins

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-10 Thread Scott Cheloha
On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote: > I dare you to write the simplest fix for this, instead of a diff that > scrolls by. This patch seems to work. Will need to bang on it for a few more days. 1. Disable gmoninit after sched_stop_scondary_cpus(). The secondary

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-10 Thread Scott Cheloha
On Mon, Jul 10, 2023 at 07:09:19AM -0600, Theo de Raadt wrote: > Mark Kettenis wrote: > > > So isn't the real problem that some of the lower-level code involved > > in the resume path isn't properly marked to not do the > > instrumentation? Traditionally that was assembly code and we'd use > >

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-09 Thread Scott Cheloha
On Sun, Jul 09, 2023 at 05:24:43PM -0500, Scott Cheloha wrote: > On Sun, Jul 09, 2023 at 08:11:43PM +0200, Claudio Jeker wrote: > > On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote: > > > This patch fixes resume/unhibernate on GPROF kernels where kgmon(8) > >

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-09 Thread Scott Cheloha
On Sun, Jul 09, 2023 at 08:11:43PM +0200, Claudio Jeker wrote: > On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote: > > This patch fixes resume/unhibernate on GPROF kernels where kgmon(8) > > has activated kernel profiling. > > > > I think the probl

GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-09 Thread Scott Cheloha
This patch fixes resume/unhibernate on GPROF kernels where kgmon(8) has activated kernel profiling. I think the problem is that code called from cpu_hatch() does not play nicely with _mcount(), so GPROF kernels crash during resume. I can't point you to which code in particular, but keeping all

glxclk(4/loongson): remove driver

2023-07-05 Thread Scott Cheloha
glxclk(4) has been compiled-but-disabled for over six months. It was disabled when loongson made the clockintr switch. Nobody has asked me to make it an intrclock option for loongson so I assume the mips64 CP0 interrupt clock is sufficient. This patch deletes the driver, driver config glue,

all platforms, kernel: remove __HAVE_CLOCKINTR symbol

2023-07-01 Thread Scott Cheloha
Every platform made the clockintr switch six months ago or more. The __HAVE_CLOCKINTR symbol is now redundant and can be removed. ok? Index: ./ddb/db_command.c === RCS file: /cvs/src/sys/ddb/db_command.c,v retrieving revision 1.98

Re: profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

2023-06-28 Thread Scott Cheloha
On Fri, Jun 23, 2023 at 04:31:59PM -0500, Scott Cheloha wrote: > On Tue, Jun 20, 2023 at 08:35:11AM -0600, Theo de Raadt wrote: > > Claudio Jeker wrote: > > > > > On Mon, Jun 19, 2023 at 06:41:14PM -0500, Scott Cheloha wrote: > > > > > On Jun 1

Re: csh(1), ksh(1), time(1): print durations with millisecond precision

2023-06-25 Thread Scott Cheloha
On Tue, Jun 13, 2023 at 10:59:53PM -0500, Scott Cheloha wrote: > This patch bumps the precision of durations printed by csh(1), ksh(1), > and time(1) from centiseconds to milliseconds. The csh(1) and ksh(1) > builtins "time" and "times" are affected. > > M

Re: profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

2023-06-23 Thread Scott Cheloha
On Tue, Jun 20, 2023 at 08:35:11AM -0600, Theo de Raadt wrote: > Claudio Jeker wrote: > > > On Mon, Jun 19, 2023 at 06:41:14PM -0500, Scott Cheloha wrote: > > > > On Jun 19, 2023, at 18:07, Theo de Raadt wrote: > > > > > > > > ???Make sur

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-20 Thread Scott Cheloha
On Tue, Jun 20, 2023 at 11:47:10AM +0200, Claudio Jeker wrote: > On Mon, Jun 19, 2023 at 04:45:03PM -0500, Scott Cheloha wrote: > > [...] > > > Index: uvm/uvm_meter.c > > === > > RCS file:

Re: profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

2023-06-19 Thread Scott Cheloha
> On Jun 19, 2023, at 18:07, Theo de Raadt wrote: > > Make sure to STOP all kernel profiling before attempting to >suspend or hibernate your machine. Otherwise I expect it >will hang. > > It is completely acceptable if it produces wrong results, but it must > not hang

Re: profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

2023-06-19 Thread Scott Cheloha
On Mon, Jun 19, 2023 at 05:40:04PM -0500, Scott Cheloha wrote: > This patch moves the profil(2)- and GPROF-specific parts of > statclock() out into their own dedicated clock interrupts. > > Test instructions will follow in a reply to this mail. This needs > testing on every pl

profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

2023-06-19 Thread Scott Cheloha
This patch moves the profil(2)- and GPROF-specific parts of statclock() out into their own dedicated clock interrupts. Test instructions will follow in a reply to this mail. This needs testing on every platform. Please reply with dmesgs and results. Non-amd64 results are greatly appreciated.

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-19 Thread Scott Cheloha
On Mon, Jun 19, 2023 at 10:22:56AM +0200, Claudio Jeker wrote: > On Sun, Jun 18, 2023 at 12:43:18PM -0500, Scott Cheloha wrote: > > On Sun, Jun 18, 2023 at 12:36:07PM -0500, Scott Cheloha wrote: > > > On Sun, Jun 18, 2023 at 07:32:56PM +0200, Mark Kettenis wrote: > > >

moncontrol(3), gprof(1): write, read gmon profiling data via utrace(2)

2023-06-18 Thread Scott Cheloha
file) != 1) errx(1, "%s: bad gmon header", filename); if ( s_highpc != 0 && ( tmp.lpc != gmonhdr.lpc || Index: usr.bin/gprof/extract.c === RCS file: usr.bin/gprof/extract.c diff -N usr.bin/gprof/extract.c --- /d

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-18 Thread Scott Cheloha
On Sun, Jun 18, 2023 at 12:36:07PM -0500, Scott Cheloha wrote: > On Sun, Jun 18, 2023 at 07:32:56PM +0200, Mark Kettenis wrote: > > > Date: Sun, 18 Jun 2023 12:27:17 -0500 > > > From: Scott Cheloha > > > > > > The intent here is to update the load ave

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-18 Thread Scott Cheloha
On Sun, Jun 18, 2023 at 07:32:56PM +0200, Mark Kettenis wrote: > > Date: Sun, 18 Jun 2023 12:27:17 -0500 > > From: Scott Cheloha > > > > The intent here is to update the load averages every five seconds. > > However: > > > > 1. Measuring elapsed tim

uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-18 Thread Scott Cheloha
The intent here is to update the load averages every five seconds. However: 1. Measuring elapsed time with the UTC clock is unreliable because of settimeofday(2). 2. "Call uvm_loadav() no more than once every five seconds", is not equivalent to "call uvm_loadav() if the current second is

Re: Pull Request: Addition of String Data Type in /sys/sys/types.h

2023-06-18 Thread Scott Cheloha
> On Jun 18, 2023, at 02:19, Abderrahmane Ghellab > wrote: > > [...] > > In my pull request , I made a > simple modification to the file by adding a new line to introduce a string > data type. Below, you can find the diff highlighting the changes made: >

Re: csh(1), ksh(1), time(1): print durations with millisecond precision

2023-06-14 Thread Scott Cheloha
On Wed, Jun 14, 2023 at 10:34:20AM -0400, Josiah Frentsos wrote: > On Tue, Jun 13, 2023 at 10:59:53PM -0500, Scott Cheloha wrote: > > Index: usr.bin/time/time.c > > === > > RCS file: /cvs/src/usr.bin/time/ti

csh(1), ksh(1), time(1): print durations with millisecond precision

2023-06-13 Thread Scott Cheloha
This patch bumps the precision of durations printed by csh(1), ksh(1), and time(1) from centiseconds to milliseconds. The csh(1) and ksh(1) builtins "time" and "times" are affected. My thinking is: - All practical OpenBSD platforms have a timecounter with at least millisecond precision. -

all platforms, main(): call clockqueue_init() just before sched_init_cpu()

2023-06-12 Thread Scott Cheloha
We need to initialize the per-CPU clockintr_queue struct before we can call clockintr_establish() from sched_init_cpu(). Initialization is done with a call to clockqueue_init(). Currently we call it during clockintr_cpu_init(), i.e. each CPU initializes its own clockintr_queue struct. This

tc_init.9: misc. cleanup

2023-03-28 Thread Scott Cheloha
- @@ -1,6 +1,7 @@ -.\"$OpenBSD: tc_init.9,v 1.11 2023/02/04 19:19:36 cheloha Exp $ +.\"$OpenBSD: tc_init.9,v 1.10 2023/01/17 10:10:11 jsg Exp $ .\" .\" Copyright (c) 2004 Alexander Yurchenko +.\" Copyright (c) 2023 Scott Cheloha .\" .\&qu

Re: timer(4/sparc64): remove driver

2023-03-25 Thread Scott Cheloha
On Fri, Mar 24, 2023 at 09:56:55AM +0100, Claudio Jeker wrote: > On Thu, Mar 23, 2023 at 05:37:05PM -0500, Scott Cheloha wrote: > > On Sat, Mar 18, 2023 at 12:17:33PM -0600, Ted Bullock wrote: > > > On 2023-03-17 12:29 p.m., Mike Larkin wrote: > > > > On Thu, Ma

Re: timer(4/sparc64): remove driver

2023-03-23 Thread Scott Cheloha
On Sat, Mar 18, 2023 at 12:17:33PM -0600, Ted Bullock wrote: > On 2023-03-17 12:29 p.m., Mike Larkin wrote: > > On Thu, Mar 16, 2023 at 12:25:15PM -0500, Scott Cheloha wrote: > >> This code has been dead since we switched sparc64 to clockintr several > >> months ag

timer(4/sparc64): remove driver

2023-03-16 Thread Scott Cheloha
This code has been dead since we switched sparc64 to clockintr several months ago. Nobody has come forward asking for a timer(4/sparc64) intrclock. As of now, you need %TICK_CMPR or %STICK_CMPR to run OpenBSD on sparc64. The only machines maybe lacking these registers are certain early

Re: kernel: don't jump ticks, jiffies during boot

2023-03-01 Thread Scott Cheloha
On Mon, Feb 27, 2023 at 08:48:53PM -0600, Scott Cheloha wrote: > On Tue, Feb 28, 2023 at 01:01:32PM +1100, Jonathan Gray wrote: > > On Mon, Feb 27, 2023 at 06:26:00PM -0600, Scott Cheloha wrote: > > > On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote: > > > &

Re: kernel: don't jump ticks, jiffies during boot

2023-02-27 Thread Scott Cheloha
On Tue, Feb 28, 2023 at 01:01:32PM +1100, Jonathan Gray wrote: > On Mon, Feb 27, 2023 at 06:26:00PM -0600, Scott Cheloha wrote: > > On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote: > > > On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote: > > >

Re: kernel: don't jump ticks, jiffies during boot

2023-02-27 Thread Scott Cheloha
On Tue, Feb 28, 2023 at 10:18:16AM +1100, Jonathan Gray wrote: > On Mon, Feb 27, 2023 at 04:57:04PM -0600, Scott Cheloha wrote: > > ticks and jiffies start at zero. During boot in initclocks(), we > > reset them: > > > > /* sys/kern/kern_clock.c */ > &g

kernel: don't jump ticks, jiffies during boot

2023-02-27 Thread Scott Cheloha
ticks and jiffies start at zero. During boot in initclocks(), we reset them: /* sys/kern/kern_clock.c */ 89 int ticks; 90 static int psdiv, pscnt;/* prof => stat divider */ 91 int psratio;/* ratio: prof / stat */ 92

timecounting: remove incomplete PPS support

2023-01-31 Thread Scott Cheloha
When the timecounting code was ported from FreeBSD in 2004 [1], stubs for pulse-per-second (PPS) polling were brought in but left disabled. They remain disabled [2]: 1.1 tholo 710: 711: #ifdef notyet 712:/* 713:

Re: hardclock: don't call statclock(), stathz is always non-zero

2023-01-31 Thread Scott Cheloha
On Mon, Jan 30, 2023 at 05:08:38PM +0100, Mark Kettenis wrote: > > Date: Sat, 21 Jan 2023 17:02:48 -0600 > > From: Scott Cheloha > > > > All the platforms have switched to clockintr. > > > > Let's start by isolating statclock() from hardclock(). stathz i

macppc, powerpc64: dec_rearm: no need to disable interrupts

2023-01-28 Thread Scott Cheloha
On macppc and powerpc64, I don't think we need to disable interrupts during dec_rearm(). ppc_mtdec() and mtdec() are just: mtspr dec, or mtdec which is atomic. Tested on macpcc (my G4). Kernel boots, system has been up for over 24 hours doing a parallel `make build`.

amd64, i386: set lapic timer mode, mask, divisor once

2023-01-27 Thread Scott Cheloha
mlarkin@ noted about a month or so ago that setting the lapic timer mode, mask, and divisor every time we rearm it is unnecessary. We only need to configure those registers once during lapic_timer_trigger(). After that, it is sufficient to set the ICR when rearming the timer. While here, add

dmtimer(4), macppc, powerpc64, riscv64: init stathz, profhz like other platforms

2023-01-26 Thread Scott Cheloha
Almost every platform initializes stathz and profhz like this: stathz = hz; profhz = stathz * 10; This patch brings a few stragglers in line with everyone else. This does not change stathz and profhz on the listed platforms: hz is 100 in every case. ok? Index:

Re: gptimer(4): switch to clockintr

2023-01-25 Thread Scott Cheloha
On Tue, Jan 24, 2023 at 10:32:49PM +0100, Mark Kettenis wrote: > > Date: Tue, 24 Jan 2023 20:57:48 +0100 > > From: Patrick Wildt > > > > Am Mon, Jan 23, 2023 at 04:34:27PM -0600 schrieb Scott Cheloha: > > > Whoops, missed one. This is the fifth and (I think)

Re: hardclock: don't call statclock(), stathz is always non-zero

2023-01-23 Thread Scott Cheloha
On Sat, Jan 21, 2023 at 05:02:49PM -0600, Scott Cheloha wrote: > All the platforms have switched to clockintr. > > Let's start by isolating statclock() from hardclock(). stathz is now > always non-zero: statclock() must be called separately. Update > several of the the stathz u

gptimer(4): switch to clockintr

2023-01-23 Thread Scott Cheloha
Whoops, missed one. This is the fifth and (I think) last armv7 clock interrupt driver that needs to switch to clockintr. gptimer(4) is nearly identical to dmtimer(4). Notable changes: - Switch stathz from 128 to hz. - Switch profhz from 1024 to (stathz * 10). Everything else in the patch is

hardclock: don't call statclock(), stathz is always non-zero

2023-01-21 Thread Scott Cheloha
All the platforms have switched to clockintr. Let's start by isolating statclock() from hardclock(). stathz is now always non-zero: statclock() must be called separately. Update several of the the stathz users to reflect that the value is always non-zero. This is a first step toward making

[v2] dmtimer(4): switch to clockintr

2023-01-10 Thread Scott Cheloha
This patch switches dmtimer(4) over to use the clockintr subsystem. This is v2. v1 is here: https://marc.info/?l=openbsd-tech=167060320326851=2 This revision fixes a bug in dmtimer_rearm() that kept the kernel from booting with the v1 patch: This revision also switches stathz from 128 to 100

Re: vmm: mask WAITPKG cpuid feature to hide TPAUSE

2023-01-08 Thread Scott Cheloha
On Sun, Jan 08, 2023 at 07:20:46PM -0500, Scott Cheloha wrote: > On Sun, Jan 08, 2023 at 03:09:44PM -0500, Dave Voutila wrote: > > > > Philip Guenther writes: > > > > > On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila wrote: > > > > > > Bringin

Re: vmm: mask WAITPKG cpuid feature to hide TPAUSE

2023-01-08 Thread Scott Cheloha
On Sun, Jan 08, 2023 at 03:09:44PM -0500, Dave Voutila wrote: > > Philip Guenther writes: > > > On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila wrote: > > > > Bringing this to tech@ to increase my chance of someone testing my > > diff. > > > > As reported in this thread on misc@ [1], I believe

[v3] sparc64: switch to clockintr

2023-01-08 Thread Scott Cheloha
Good news! I have tested this revision in a T4-2 LDOM with help from kn@. Booted the patched kernel, built a release, booted the resulting bsd.rd, upgraded, booted into the upgrade kernel. The whole cycle. It all worked. In this revision I believe I am *now* using send_softint() correctly,

[v2] sparc64: switch to clockintr

2023-01-04 Thread Scott Cheloha
Now that we have resolved the problems with the UltraSPARC IIe, let's try the clockintr switch again. For reference, here is v1: https://marc.info/?l=openbsd-tech=166776418803680=2 The major difference in v2 is that we send_softint() if we miss when setting the comparison register instead of

Re: [v3] timeout.9: document missing interfaces, miscellaneous rewrites

2022-12-31 Thread Scott Cheloha
t; elbow from more than a year of medicine ball ping pong. ;-) These rewrites tend to gather a lot of moss, yeah :) > The following are merely suggestions / observations / questions, > not conditions. > > Scott Cheloha wrote on Sat, Dec 31, 2022 at 11:22:22AM -0500: >

Re: ssh: progress meter: prefer setitimer(2) to alarm(3)

2022-12-31 Thread Scott Cheloha
On Sat, Dec 31, 2022 at 07:05:20PM +0100, Mark Kettenis wrote: > > Date: Sat, 31 Dec 2022 10:33:26 -0500 > > From: Scott Cheloha > > > > Here's another one. > > > > The progress meter in scp(1) and sftp(1) updates periodically, once > > per secon

[v3] timeout.9: document missing interfaces, miscellaneous rewrites

2022-12-31 Thread Scott Cheloha
1.55 +++ timeout.9 31 Dec 2022 16:19:27 - @@ -1,6 +1,7 @@ .\"$OpenBSD: timeout.9,v 1.55 2022/06/22 14:10:49 visa Exp $ .\" .\" Copyright (c) 2000 Artur Grabowski +.\" Copyright (c) 2021, 2022 Scott Cheloha .\" All rights reserved. .\" .\&quo

  1   2   3   4   5   6   7   8   9   10   >