Re: monotonic time going back by wrong skews

2021-04-07 Thread Scott Cheloha
On Wed, Apr 07, 2021 at 06:18:40PM +0200, Mark Kettenis wrote: > > From: Scott Cheloha > > Date: Wed, 7 Apr 2021 10:25:04 -0500 > > > > > On Apr 6, 2021, at 07:49, Paul Irofti wrote: > > > > > >>>> The diff is obviously fine. But it is sti

Re: monotonic time going back by wrong skews

2021-04-07 Thread Scott Cheloha
> On Apr 6, 2021, at 07:49, Paul Irofti wrote: > The diff is obviously fine. But it is still a heuristic with no real motivation except for this particular ESXi VM case. So my question about why we choose the minimum instead of the median or the mean has not been answered.

amd64: add MSR_TSC_ADJUST

2021-04-05 Thread Scott Cheloha
Intel calls it "IA32_TSC_ADJUST". Is "MSR_TSC_ADJUST" fine or should it be "MSR_IA32_TSC_ADJUST"? We have a feature flag for this one already, SEFF0EBX_TSC_ADJUST. Index: specialreg.h === RCS file:

Re: monotonic time going back by wrong skews

2021-04-05 Thread Scott Cheloha
On Mon, Apr 05, 2021 at 09:29:10PM +0200, Marcus MERIGHI wrote: > Hello! > > scottchel...@gmail.com (Scott Cheloha), 2021.03.25 (Thu) 23:28 (CET): > > Feel free to share your raw data. > > I think I followed the instructions; is it expected to get a lot of > >

Re: monotonic time going back by wrong skews

2021-04-05 Thread Scott Cheloha
> On Apr 5, 2021, at 09:07, Stuart Henderson wrote: > > I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2. > This is a machine which has "disabling user TSC (skew=XXX)" reported for > some cores: > > Nov 5 16:08:34 pweb /bsd: cpu11: disabling user TSC (skew=-107) > Nov

Re: monotonic time going back by wrong skews

2021-04-04 Thread Scott Cheloha
On Mon, Mar 29, 2021 at 02:00:01PM +0900, YASUOKA Masahiko wrote: > On Thu, 25 Mar 2021 19:41:35 +0100 (CET) > Mark Kettenis wrote: > >> From: Scott Cheloha > >> Date: Thu, 25 Mar 2021 13:18:04 -0500 > >> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Mas

Re: monotonic time going back by wrong skews

2021-04-03 Thread Scott Cheloha
On Fri, Apr 02, 2021 at 10:37:36AM -0700, Mike Larkin wrote: > On Thu, Apr 01, 2021 at 06:43:30PM -0500, Scott Cheloha wrote: > > > > [...] > > > > Hmmm. Being able to work around this would be nice. > > > > FreeBSD has code that uses WRMS

Re: monotonic time going back by wrong skews

2021-04-01 Thread Scott Cheloha
On Thu, Apr 01, 2021 at 03:41:24PM -0400, Josh Rickmar wrote: > On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote: > > On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote: > > > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > > >

Re: monotonic time going back by wrong skews

2021-04-01 Thread Scott Cheloha
On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > Feel free to share your raw data. > > Also includes some standard sendbug dumps: https://0x0.st/-qng.tgz Thanks! TL;DR: Two things: 1. Could you check whether Linux will use the TSC as a clocksource on this machine? The dmesg

Re: monotonic time going back by wrong skews

2021-03-25 Thread Scott Cheloha
On Thu, Mar 25, 2021 at 07:24:23PM -0400, Josh Rickmar wrote: > On Thu, Mar 25, 2021 at 05:28:54PM -0500, Scott Cheloha wrote: > > Feel free to share your raw data. > > Attached. Hmmm, interesting stuff. $ ministat -q cpu* x cpu1-skew + cpu2-skew * cpu3-skew % c

Re: monotonic time going back by wrong skews

2021-03-25 Thread Scott Cheloha
On Thu, Mar 25, 2021 at 02:33:43PM -0400, Josh Rickmar wrote: > On Thu, Mar 25, 2021 at 01:18:04PM -0500, Scott Cheloha wrote: > > > On Mar 24, 2021, at 8:29 AM, Josh Rickmar wrote: > > > > > > [...] > > > > Which diff did you apply? Yasuoka provid

Re: monotonic time going back by wrong skews

2021-03-25 Thread Scott Cheloha
> On Mar 24, 2021, at 8:29 AM, Josh Rickmar wrote: > > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote: >> Hi, >> >> I hit a problem which is caused by going back of monotonic time. It >> happens on hosts on VMware ESXi. >> >> I wrote the program which repeats the problem. >>

Re: syslogd kernel timestamp

2021-03-21 Thread Scott Cheloha
On Thu, Mar 18, 2021 at 05:57:45PM +0100, Alexander Bluhm wrote: > Hi, > > Since we stash log messages in the kernel, the timestamps added by > syslogd are delayed. The kernel could add the timestamp when it > receives the message by sendsyslog(2). This is more precise and > can be expressed by

sparc64/clock.c: use ANSI-style function definitions

2021-02-23 Thread Scott Cheloha
I'm poking around in this file and lo, K function definitions. Any reason not to ANSIfy these? While we're here we can kill some ARGUSED comments, too. I don't have a sparc64 machine so I'd appreciate a test compile. Assuming it compiles, ok? Index: clock.c

timecounting: use C99-style initialization for all timecounter structs

2021-02-18 Thread Scott Cheloha
Hi, If the timecounter struct changes again in the future it will be easier to make the change if we are using C99-style initialization everywhere. In general I think C99-style initialization is easier to read for larger structs. The timecounter struct definitely qualifies as "larger". We

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-14 Thread Scott Cheloha
On Thu, Jan 07, 2021 at 11:15:42AM -0600, Scott Cheloha wrote: > Hi, > > I want to isolate statclock() from hardclock(9). This will simplify > the logic in my WIP dynamic clock interrupt framework. > > Currently, if stathz is zero, we call statclock() from within > hardclo

Re: tpm(4): don't use tvtohz(9)

2021-01-13 Thread Scott Cheloha
On Fri, Jan 08, 2021 at 08:21:14PM +0100, Florian Obser wrote: > On Fri, Jan 08, 2021 at 11:48:33AM -0600, Scott Cheloha wrote: > > On Fri, Jan 08, 2021 at 05:41:24PM +0100, Mark Kettenis wrote: > > > > Date: Fri, 8 Jan 2021 10:27:38 -0600 > > > > From: Scott Chel

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-13 Thread Scott Cheloha
On Sat, Jan 09, 2021 at 12:52:22PM -0600, Dale Rahn wrote: > The 'magic' here was that MD code could choose to implement statclock (and > set stathz appropriately), or MD code could not care about the multiple > statclock/hardclock interfaces into the scheduler. Also some clock drivers > on a

sysctl(8), kernel: remove dead variable: tickadj

2021-01-08 Thread Scott Cheloha
The global variable "tickadj" has no users in the kernel anymore and should be eliminated from all code and documentation. At one time "tickadj" controlled the skew rate for adjtime(2), but it has been unused since the modern timecounting subsystem was imported from FreeBSD circa 2004-2005.

Re: sleep_setup/finish simplification

2021-01-08 Thread Scott Cheloha
On Mon, Dec 28, 2020 at 11:41:52AM -0300, Martin Pieuchot wrote: > On 08/12/20(Tue) 10:06, Martin Pieuchot wrote: > > Diff below aims to simplify the API to put a thread on a sleep queue and > > reduce it to the following: > > > > sleep_setup(); > > /* check condition or release lock */ >

Re: tpm(4): don't use tvtohz(9)

2021-01-08 Thread Scott Cheloha
On Fri, Jan 08, 2021 at 05:41:24PM +0100, Mark Kettenis wrote: > > Date: Fri, 8 Jan 2021 10:27:38 -0600 > > From: Scott Cheloha > > > > On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote: > > > > Date: Wed, 6 Jan 2021 16:16:27 -0600 > > > &

Re: tpm(4): don't use tvtohz(9)

2021-01-08 Thread Scott Cheloha
On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote: > > Date: Wed, 6 Jan 2021 16:16:27 -0600 > > From: Scott Cheloha > > > > On Wed, Jan 06, 2021 at 12:16:13PM -0600, Scott Cheloha wrote: > > > As mentioned in a prior mail, tpm(4) is the last us

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-08 Thread Scott Cheloha
On Thu, Jan 07, 2021 at 08:12:10PM -0600, Scott Cheloha wrote: > On Thu, Jan 07, 2021 at 09:37:58PM +0100, Mark Kettenis wrote: > > > Date: Thu, 7 Jan 2021 11:15:41 -0600 > > > From: Scott Cheloha > > > > > > Hi, > > > > > > I want to i

Re: all platforms: isolate hardclock(9) from statclock()

2021-01-07 Thread Scott Cheloha
On Thu, Jan 07, 2021 at 09:37:58PM +0100, Mark Kettenis wrote: > > Date: Thu, 7 Jan 2021 11:15:41 -0600 > > From: Scott Cheloha > > > > Hi, > > > > I want to isolate statclock() from hardclock(9). This will simplify > > the logic in my WIP dynamic clo

Re: syncer_thread: sleep without lbolt

2021-01-07 Thread Scott Cheloha
On Sat, Dec 12, 2020 at 01:32:13PM -0600, Scott Cheloha wrote: > Hi, > > The syncer thread is one of the last users of the lbolt (lightning > bolt!) sleep channel. > > If we add a syncer-specific sleep channel (syncer_chan) and do a bit > of time math we can replicate

all platforms: isolate hardclock(9) from statclock()

2021-01-07 Thread Scott Cheloha
Hi, I want to isolate statclock() from hardclock(9). This will simplify the logic in my WIP dynamic clock interrupt framework. Currently, if stathz is zero, we call statclock() from within hardclock(9). It looks like this (see sys/kern/kern_clock.c): void hardclock(struct clockframe *frame) {

Re: tpm(4): don't use tvtohz(9)

2021-01-06 Thread Scott Cheloha
On Wed, Jan 06, 2021 at 12:16:13PM -0600, Scott Cheloha wrote: > As mentioned in a prior mail, tpm(4) is the last user of tvtohz(9) in > the tree. > > However, we don't need to use tvtohz(9) in tpm(4) at all. Converting > from milliseconds to ticks is trivial. Using an inter

tpm(4): don't use tvtohz(9)

2021-01-06 Thread Scott Cheloha
As mentioned in a prior mail, tpm(4) is the last user of tvtohz(9) in the tree. However, we don't need to use tvtohz(9) in tpm(4) at all. Converting from milliseconds to ticks is trivial. Using an intermediary timeval is just pointless indirection. With this committed I will be able to remove

sleep(3): don't bypass nanosleep(2)

2021-01-06 Thread Scott Cheloha
In sleep(3), if seconds is zero we don't call nanosleep(2). I don't like this. If sleep(3) really is a simplified interface to nanosleep(2) (as we claim in the manpage) we should let nanosleep(2) handle the input and make decisions. Other benefits: - sleep(3) now *always* shows up in ktrace.

Re: bpf(4): remove ticks

2020-12-28 Thread Scott Cheloha
On Mon, Dec 28, 2020 at 10:49:59AM +1000, David Gwynne wrote: > On Sat, Dec 26, 2020 at 04:48:23PM -0600, Scott Cheloha wrote: > > Now that we've removed bd_rdStart from the bpf_d struct, removing > > ticks from bpf(4) itself is straightforward. > > > > - bd_rtout

bpf(4): remove ticks

2020-12-26 Thread Scott Cheloha
Now that we've removed bd_rdStart from the bpf_d struct, removing ticks from bpf(4) itself is straightforward. - bd_rtout becomes a timespec; update bpfioctl() accordingly. Cap it at MAXTSLP nanoseconds to avoid arithmetic overflow in bpfread(). - At the start of bpfread(), if a timeout is

kernel: more lbolt removal

2020-12-25 Thread Scott Cheloha
Here's some more sleeps that use lbolt that could use and a timeout for 1 second. There are some trickier lbolt sleeps in the tty code that I have omitted, plus the lbolt sleep in the vfs syncer thread. Otherwise, lbolt is dead with this patch. ok? Index: uvm/uvm_fault.c

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

2020-12-25 Thread Scott Cheloha
On Wed, Dec 16, 2020 at 10:04:48PM +0100, Mark Kettenis wrote: > > Date: Wed, 16 Dec 2020 12:50:46 -0600 > > From: Scott Cheloha > > > > On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > > > Date: Tue, 15 Dec 2020 13:32:

Re: tsleep(9): add global "nowake" channel

2020-12-23 Thread Scott Cheloha
On Thu, Dec 24, 2020 at 12:24:01AM +0100, Patrick Wildt wrote: > Am Wed, Dec 23, 2020 at 05:04:23PM -0600 schrieb Scott Cheloha: > > On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote: > > > I agree. This chunk below is really gross and does not follow the > >

Re: tsleep(9): add global "nowake" channel

2020-12-23 Thread Scott Cheloha
On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote: > I agree. This chunk below is really gross and does not follow the > special wakeup channel metaphor. > > It is *entirely clear* that a called "nowake" has no wakeup. > Like duh. > > > +/* > > + * nowake is a global sleep channel

Re: i386: apm(4): apm_thread(): sleep without lbolt

2020-12-23 Thread Scott Cheloha
On Tue, Dec 15, 2020 at 09:15:31AM -0300, Martin Pieuchot wrote: > On 11/12/20(Fri) 19:17, Scott Cheloha wrote: > > Here's another sleep that doesn't need lbolt. > > > > The idea here is to call apm_periodic_check() once a second. > > We can do that without lbolt. &

tsleep(9): add global "nowake" channel

2020-12-23 Thread Scott Cheloha
Okay, let's try one more time. This patch adds a global sleep channel, "nowake", for sleeping threads that don't want to receive wakeup(9) broadcasts. You use it like this: #include tsleep(nowake, ...); I've added additional assertions to tsleep, msleep, and rwsleep that

Re: pool(9): remove ticks (attempt 2)

2020-12-23 Thread Scott Cheloha
On Fri, Dec 11, 2020 at 05:32:54PM -0600, Scott Cheloha wrote: > On Fri, Dec 11, 2020 at 07:52:45PM +0100, Mark Kettenis wrote: > > > Date: Fri, 11 Dec 2020 11:51:54 -0600 > > > From: Scott Cheloha > > > > > > On Fri, Dec 11, 2020 at 09:49:07AM -0300, Mart

prototype of delay(9) is inconsistent

2020-12-21 Thread Scott Cheloha
The manpage for delay(9) suggests that the prototype is: void delay(int); But on armv7, arm64, hppa, macppc, and powerpc64 the input is unsigned or a u_int instead of an int. Like this: void delay(unsigned); or this: void delay(u_int); Can we pick a prototype and stick to it? An upside of

[please test] acpi: more *sleep(9) -> *sleep_nsec(9) conversions

2020-12-20 Thread Scott Cheloha
Short version: Please test if this patch breaks suspend or hibernate on your machine. Reply with the results of your test and your dmesg. Both are still working on my Lenovo Thinkpad X1 Carbon Gen 6. Long version: This patch converts the remaining tick sleeps in dev/acpi to nanosecond sleeps.

Re: sigsuspend(2): use "sigsuspend" for sleep string

2020-12-20 Thread Scott Cheloha
On Sun, Dec 20, 2020 at 10:11:07PM +0100, Mark Kettenis wrote: > > Date: Sun, 20 Dec 2020 14:53:16 -0600 > > From: Scott Cheloha > > > > I want to see if a process is waiting in sigsuspend(2) from top(1). > > The current sleep string is "pause", which

sigsuspend(2): use "sigsuspend" for sleep string

2020-12-20 Thread Scott Cheloha
I want to see if a process is waiting in sigsuspend(2) from top(1). The current sleep string is "pause", which leaves me wondering what the process is actually doing. The string "sigsuspend" would make it unambiguous. ok? Index: kern_sig.c

Re: tpm(4): removing tvtohz(9)?

2020-12-19 Thread Scott Cheloha
> On Dec 18, 2020, at 20:16, joshua stein wrote: > > On Fri, 18 Dec 2020 at 18:58:43 -0600, Scott Cheloha wrote: >> Hi, >> >> tpm(4) is the last driver in the tree using tvtohz(9). There are no >> remaining callers using tstohz(9), so if and when we remov

tpm(4): removing tvtohz(9)?

2020-12-18 Thread Scott Cheloha
Hi, tpm(4) is the last driver in the tree using tvtohz(9). There are no remaining callers using tstohz(9), so if and when we remove tvtohz(9) from tpm(4) we can remove both interfaces from the tree. tpm(4) is tricky because it converts timeouts from milliseconds to ticks and then doesn't use

tsleep(9): sleep on private channel if ident is NULL

2020-12-18 Thread Scott Cheloha
Hi, This patch adds support for passing NULL as the ident when calling tsleep(9) etc. When this happens, sleep_setup() will use the address of the sleep_state struct as the value for p_wchan. This address is basically always a private value so the thread should never receive a wakeup(9)

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

2020-12-16 Thread Scott Cheloha
> On Dec 16, 2020, at 18:40, Martin Pieuchot wrote: > > On 16/12/20(Wed) 23:23, Claudio Jeker wrote: >>> On Wed, Dec 16, 2020 at 04:50:42PM -0300, Martin Pieuchot wrote: >>> [...] >>> Why did we choose to use a variable over NULL? Any technical reason? >> >> The sleep subsytem requires a

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

2020-12-16 Thread Scott Cheloha
On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > Date: Tue, 15 Dec 2020 13:32:22 +0100 > > From: Claudio Jeker > > > > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote: > > > Hi, > > > > > > I'd li

Re: tht(4): more tsleep(9) -> tsleep_nsec(9) conversions

2020-12-16 Thread Scott Cheloha
On Thu, Dec 03, 2020 at 09:59:11PM -0600, Scott Cheloha wrote: > Hi, > > tht(4) is another driver still using tsleep(9). > > It uses it to spin while it waits for the card to load the firmware. > Then it uses it to spin for up to 2 seconds while waiting for >

Re: sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

2020-12-15 Thread Scott Cheloha
On Tue, Dec 15, 2020 at 01:47:24PM +0100, Mark Kettenis wrote: > > Date: Tue, 15 Dec 2020 13:32:22 +0100 > > From: Claudio Jeker > > > > On Fri, Dec 11, 2020 at 07:07:56PM -0600, Scott Cheloha wrote: > > > Hi, > > > > > > I'd li

syncer_thread: sleep without lbolt

2020-12-12 Thread Scott Cheloha
Hi, The syncer thread is one of the last users of the lbolt (lightning bolt!) sleep channel. If we add a syncer-specific sleep channel (syncer_chan) and do a bit of time math we can replicate the current behavior and remove another lbolt user. This isn't a perfect recreation of the current

i386: apm(4): apm_thread(): sleep without lbolt

2020-12-11 Thread Scott Cheloha
Here's another sleep that doesn't need lbolt. The idea here is to call apm_periodic_check() once a second. We can do that without lbolt. Is there some other address that would be more appropriate for this thread to sleep on? It doesn't look like any apm(4) code calls wakeup(9) on lbolt so I've

sdmmc(4): sdmmc_io_function_enable(): don't sleep on lbolt

2020-12-11 Thread Scott Cheloha
Hi, I'd like to remove lbolt from the kernel. I think having it in the kernel complicates otherwise simple code. We can start with sdmmc(4). The goal in sdmmc_io_function_enable() is calling sdmmc_io_function_ready() up to six times and sleep 1 second between each attempt. Here's rewritten

Re: pool(9): remove ticks (attempt 2)

2020-12-11 Thread Scott Cheloha
On Fri, Dec 11, 2020 at 07:52:45PM +0100, Mark Kettenis wrote: > > Date: Fri, 11 Dec 2020 11:51:54 -0600 > > From: Scott Cheloha > > > > On Fri, Dec 11, 2020 at 09:49:07AM -0300, Martin Pieuchot wrote: > > > > > > I'm not sure to understand,

Re: pool(9): remove ticks (attempt 2)

2020-12-11 Thread Scott Cheloha
On Fri, Dec 11, 2020 at 09:49:07AM -0300, Martin Pieuchot wrote: > On 11/12/20(Fri) 12:52, Mark Kettenis wrote: > > > Date: Thu, 10 Dec 2020 16:13:22 -0600 > > > From: Scott Cheloha > > > > > > Hi, > > > > > > We looked at removing

cat(1): -n flag: support files with more than INT_MAX lines

2020-12-10 Thread Scott Cheloha
Hi, If we bump 'line' from an int to an unsigned long long we will correctly number files with more than INT_MAX lines instead of wrapping to a negative number. ok? Index: cat.c === RCS file: /cvs/src/bin/cat/cat.c,v retrieving

Re: ipmi(4): ipmi_poll_thread(): tsleep(9) -> tsleep_nsec(9)

2020-12-10 Thread Scott Cheloha
On Thu, Dec 10, 2020 at 10:00:46AM +0100, Claudio Jeker wrote: > On Mon, Dec 07, 2020 at 10:54:26PM -0600, Scott Cheloha wrote: > > Index: ipmi.c > > === > > RCS file: /cvs/src/sys/dev/ipmi.c,v > > retriev

pool(9): remove ticks (attempt 2)

2020-12-10 Thread Scott Cheloha
Hi, We looked at removing the ticks from subr_pool.c a while back but it got shelved. That may or may not have been my fault. I don't remember. Anyway, I would normally suggest switching to getuptime(9) here, but getuptime(9) counts in seconds and we're working with a 1 second timeout in this

bpf(4): BIOCGRTIMEOUT, BIOCSRTIMEOUT: protect with bd_mtx

2020-12-10 Thread Scott Cheloha
Hi, Before converting bpf(4) from using ticks to using real units of time we need to serialize BIOCGRTIMEOUT and BIOCSRTIMEOUT. Neither operation is atomic so we need to use the per-descriptor mutex when reading or writing the bd_rtout member. While here we can start annotating the locking for

Re: ipmi(4): ipmi_poll_thread(): tsleep(9) -> tsleep_nsec(9)

2020-12-07 Thread Scott Cheloha
On Wed, Dec 02, 2020 at 11:43:32PM +0100, Mark Kettenis wrote: > > From: "Constantine A. Murenin" > > Date: Wed, 2 Dec 2020 14:04:52 -0800 > > > > Not sure if you've seen it, but ipmi(4) has been disabled for over 12 > > years, because it's broken on some machines, so, this code is not > >

Re: srp_finalize(9): tsleep(9) -> tsleep_nsec(9)

2020-12-04 Thread Scott Cheloha
On Fri, Dec 04, 2020 at 09:56:02AM +0100, Claudio Jeker wrote: > On Thu, Dec 03, 2020 at 10:05:30PM -0600, Scott Cheloha wrote: > > Hi, > > > > srp_finalize(9) uses tsleep(9) to spin while it waits for the object's > > refcount to reach zero. It blocks for u

Re: mbg(4): tsleep(9) -> tsleep_nsec(9)

2020-12-04 Thread Scott Cheloha
On Fri, Dec 04, 2020 at 10:07:07AM +0100, Claudio Jeker wrote: > On Thu, Dec 03, 2020 at 10:42:50PM -0600, Scott Cheloha wrote: > > Hi, > > > > mbg(4) is among the few remaining drivers using tsleep(9). > > > > In a few spots, when the kernel is not cold, the dr

mbg(4): tsleep(9) -> tsleep_nsec(9)

2020-12-03 Thread Scott Cheloha
Hi, mbg(4) is among the few remaining drivers using tsleep(9). In a few spots, when the kernel is not cold, the driver will spin for up to 1/10 seconds waiting for the MBG_BUSY flag to go low. We can approximate this behavior by spinning 10 times and sleeping 10 milliseconds each iteration. 10

srp_finalize(9): tsleep(9) -> tsleep_nsec(9)

2020-12-03 Thread Scott Cheloha
Hi, srp_finalize(9) uses tsleep(9) to spin while it waits for the object's refcount to reach zero. It blocks for up to 1 tick and then checks the refecount again and again. We can just as easily do this with tsleep_nsec(9) and block for 1 millisecond per interval. ok? Index: kern_srp.c

tht(4): more tsleep(9) -> tsleep_nsec(9) conversions

2020-12-03 Thread Scott Cheloha
Hi, tht(4) is another driver still using tsleep(9). It uses it to spin while it waits for the card to load the firmware. Then it uses it to spin for up to 2 seconds while waiting for THT_REG_INIT_STATUS. In the firmware case we can sleep for 10 milliseconds each iteration. In the

hvn(4): msleep(9) -> msleep_nsec(9)

2020-12-03 Thread Scott Cheloha
Hi, In hvn_alloc_cmd() we spin within a mutex while the freelist is empty. Because we're using a mutex there is no way to miss the wakeup(9) from hvn_free_cmd(), so we don't even need a timeout here. Instead of doing msleep(9) for 1 tick repeatedly we can msleep_nsec(9) without a timeout

softraid(4): more tsleep(9) -> tsleep_nsec(9) conversions

2020-12-03 Thread Scott Cheloha
Hi, softraid(4) is another driver still using tsleep(9). softraid(4) uses tsleep(9) in one spot to poll for completion. It uses it in two other spots to momentarily yield the CPU to permit a different thread to make progress. In all cases the length of the timeout is totally arbitrary. We're

ipmi(4): ipmi_poll_thread(): tsleep(9) -> tsleep_nsec(9)

2020-12-02 Thread Scott Cheloha
Hi, ipmi(4) is one of the few remaining callers of tsleep(9). I want to convert it to use tsleep_nsec(9) but I need some clarification on what the code in question is doing. In ipmi_poll_thread() we initialize all the sensors in a loop. Between each get_sdr() call we tsleep(9) for 1 tick. So,

hvn(4), hyperv(4): tsleep(9) -> tsleep_nsec(9)

2020-12-02 Thread Scott Cheloha
Hi, I'd like to convert all of the wait loops in hvn(4) and hyperv(4) from using ticks to using real units of time. Most of them use tsleep(9), so let's do tsleep(9) -> tsleep_nsec(9) conversions first. In every case there is an adjacent delay(9) call we use if the kernel is cold. I assume

Re: stdio: fclose(3), fopen(3): intended locking hierarchy?

2020-12-01 Thread Scott Cheloha
On Mon, Nov 30, 2020 at 08:44:41PM -0800, Philip Guenther wrote: > On Mon, Nov 30, 2020 at 6:10 PM Scott Cheloha > wrote: > > > On Sat, Nov 28, 2020 at 01:41:50PM -0800, Philip Guenther wrote: > > > ... > > > > After thinking through states more

Re: stdio: fclose(3), fopen(3): intended locking hierarchy?

2020-11-30 Thread Scott Cheloha
On Sat, Nov 28, 2020 at 01:41:50PM -0800, Philip Guenther wrote: > On Fri, Nov 27, 2020 at 10:35 PM Philip Guenther wrote: > ... > > > So yeah, maybe it does work to: > > 1) make __sfp() FLOCKFILE() the allocated FILE before unlocking sfp_mutex > > 2) update f{,d,mem,un}open() and

Re: stdio: fclose(3), fopen(3): intended locking hierarchy?

2020-11-30 Thread Scott Cheloha
On Fri, Nov 27, 2020 at 10:35:59PM -0800, Philip Guenther wrote: > On Wed, Nov 25, 2020 at 4:23 PM Scott Cheloha > wrote: > > > In stdio, which lock are you supposed to take first? The global > > sfp_mutex or the per-FILE lock? > > > > In __sfp() we hold

Re: an(4): tsleep(9) -> tsleep_nsec(9)

2020-11-30 Thread Scott Cheloha
On Thu, Nov 26, 2020 at 08:25:48PM +1100, Jonathan Gray wrote: > On Tue, Nov 24, 2020 at 07:20:46PM -0600, Scott Cheloha wrote: > > Hi, > > > > Both kettenis@ and mpi@ have mentioned in private that my proposed > > changes to tsleep_nsec(9) etc. would be nic

cat(1): simplify/flatten argument loops

2020-11-30 Thread Scott Cheloha
Hi, The cook_args() and raw_args() functions in cat(1) are too clever. They handle multiple special cases in a single big loop with lots of branches. It's been like this since at least 1989: https://svnweb.freebsd.org/csrg/bin/cat/cat.c?view=markup=37179 The goal seems to be to avoid calling

stdio: fclose(3), fopen(3): intended locking hierarchy?

2020-11-25 Thread Scott Cheloha
Hey, In stdio, which lock are you supposed to take first? The global sfp_mutex or the per-FILE lock? In __sfp() we hold sfp_mutex while iterating through the pool (unsure what else to call it) of FILEs. No two threads can modify the pool at the same time: 111

an(4): tsleep(9) -> tsleep_nsec(9)

2020-11-24 Thread Scott Cheloha
Hi, Both kettenis@ and mpi@ have mentioned in private that my proposed changes to tsleep_nsec(9) etc. would be nicer if we could just get rid of tsleep(9) etc. entirely. This is difficult, but I'll try. Worst case, we thin out the remaining callers. There are not many left. -- So, an(4) is

setitimer(2): protect per-process ITIMER_REAL state with ps_mtx

2020-10-27 Thread Scott Cheloha
Hi, The last step before unlocking setitimer(2) and getitimer(2) is protecting the per-process ITIMER_REAL state with something other than the kernel lock. Because the ITIMER_REAL timeout runs at IPL_SOFTCLOCK I think the per-process mutex ps_mtx is appropriate. Changing the setitimer() routine

Re: Please test: switch select(2) to kqfilters

2020-10-26 Thread Scott Cheloha
On Mon, Oct 12, 2020 at 11:11:36AM +0200, Martin Pieuchot wrote: > On 09/10/20(Fri) 10:38, Martin Pieuchot wrote: > > On 02/10/20(Fri) 12:19, Martin Pieuchot wrote: > > > Diff below modifies the internal implementation of {p,}select(2) to > > > query kqfilter handlers instead of poll ones. > > >

calctsru(): simplify code

2020-10-25 Thread Scott Cheloha
calctsru() can be simplified. Its length makes it look more complicated than it really is. We're converting from ticks to nanoseconds and storing nanoseconds in a timespec: - Remove the check for zero. Pointless. - Convert from ticks to nanoseconds inline. No intermediate variables. - Use

sys/kernel.h: delete dead externs

2020-10-15 Thread Scott Cheloha
Several of the externs in sys/kernel.h are for variables that don't exist. I can't find global declarations for tickfix, tickfixinterval, tickdelta, or timedelta. ok to delete these? Index: sys/kernel.h === RCS file:

Re: _exit(2), execve(2): cancel interval timers MP-safely

2020-10-14 Thread Scott Cheloha
On Wed, Oct 14, 2020 at 08:06:52PM -0500, Scott Cheloha wrote: > _exit(2) and execve(2) need to obey the locking protocol described in > proc.h when manipulating the per-process interval timer state. > > While we're here we can also remove the now pointless splclock/splx > danc

_exit(2), execve(2): cancel interval timers MP-safely

2020-10-14 Thread Scott Cheloha
_exit(2) and execve(2) need to obey the locking protocol described in proc.h when manipulating the per-process interval timer state. While we're here we can also remove the now pointless splclock/splx dance from execve(2). The easiest way to obey the locking protocol is to reuse the interface

Re: timeout(9): add clock-based timeouts (attempt 2)

2020-10-09 Thread Scott Cheloha
Hey, > On Oct 7, 2020, at 8:49 PM, 内藤 祐一郎 wrote: > > Hi. > > I'm looking forward to this patch is committed. > Because this patch solves my problem about CARP timeout. > > IIJ, a company that I am working for, is using carp(4) on VMware ESXi hosts > for VPN and web gateway services. > > One

Re: setitimer(2): ITIMER_REAL: simplify realitexpire()

2020-10-07 Thread Scott Cheloha
> On Oct 7, 2020, at 15:51, Klemens Nanni wrote: > > On Wed, Oct 07, 2020 at 03:34:36PM -0500, Scott Cheloha wrote: >> kn@ wanted to clean it up a while ago but I wan't far enough along >> with hi-res timeouts to change the code yet. > That was not me. I am thinking of

setitimer(2): ITIMER_REAL: simplify realitexpire()

2020-10-07 Thread Scott Cheloha
Hi, The code in realitexpire(), the ITIMER_REAL timeout callback, is needlessly complicated. kn@ wanted to clean it up a while ago but I wan't far enough along with hi-res timeouts to change the code yet. Hi-res timeouts are now imminent, and setitimer(2) will probably be the first guinnea pig

Re: Please test: switch select(2) to kqfilters

2020-10-04 Thread Scott Cheloha
On Sat, Oct 03, 2020 at 09:09:00AM +0200, Martin Pieuchot wrote: > On 02/10/20(Fri) 19:09, Scott Cheloha wrote: > > On Fri, Oct 02, 2020 at 12:19:35PM +0200, Martin Pieuchot wrote: > > > @@ -635,12 +642,39 @@ sys_kevent(struct proc *p, void *v, regi > &g

Re: Please test: switch select(2) to kqfilters

2020-10-02 Thread Scott Cheloha
On Fri, Oct 02, 2020 at 12:19:35PM +0200, Martin Pieuchot wrote: > > [...] > > I'd like to get this in early in this release cycle, so please test and > report back :o) You removed the resleep logic that accounts for if/when tsleep_nsec(9) returns early. So now select and pselect can return

Re: getitimer(2), setitimer(2): merge critical sections

2020-09-25 Thread Scott Cheloha
On Tue, Sep 01, 2020 at 10:24:11AM -0500, Scott Cheloha wrote: > On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote: > > > > [...] > > Two week bump. > > In summary: > > - Merge the critical sections so that "timer swap" with setitimer(2) &

setpriority(2): booleans are not scalars

2020-09-25 Thread Scott Cheloha
`found' serves as a boolean here. I'd prefer to simple and set it to 1 instead of incrementing it when we find what we're looking for. ok? Index: kern_resource.c === RCS file: /cvs/src/sys/kern/kern_resource.c,v retrieving revision

Re: amap: panic -> KASSERT

2020-09-25 Thread Scott Cheloha
> On Sep 24, 2020, at 07:43, Theo de Raadt wrote: > > Mark Kettenis wrote: > >>> Date: Thu, 24 Sep 2020 11:53:59 +0200 >>> From: Martin Pieuchot >>> >>> Convert various "if (x) panic()" idioms into "KASSERT(!x)". The panic >>> message isn't helping for such sanity checks and this help

top(1): display uptime in HH:MM:SS format

2020-09-18 Thread Scott Cheloha
Hi, After fussing with top(1)'s uptime display a bit I now think: - An HH:MM:SS format uptime is useful in top(1). It's also more visually consistent with the local timestamp printed on the line above it, so it is easier to read at a glance. - The variable printing of "days" is annoying.

kstat(1): implement wait with setitimer(2)

2020-09-17 Thread Scott Cheloha
Hi, Using nanosleep(2) to print the stats periodically causes the period to drift. If you use setitimer(2) it won't drift. ok? Index: kstat.c === RCS file: /cvs/src/usr.bin/kstat/kstat.c,v retrieving revision 1.6 diff -u -p -r1.6

Re: systat(1): vmstat: compute rates with CLOCK_UPTIME

2020-09-16 Thread Scott Cheloha
On Wed, Sep 16, 2020 at 01:20:16AM -0600, Theo de Raadt wrote: > Two days ago during my work on ongoing work for non-acpi suspend, > kettenis and I observed the same thing. > > your diff works very well for me. Okay, so I'm not the only one. Let's do the full patch: - All rates in the vmstat

systat(1): vmstat: compute rates with CLOCK_UPTIME

2020-09-15 Thread Scott Cheloha
Hi, systat(1)'s vmstat view displays rates for things like interrupts. Strangely, it uses CPU time to compute these rates, not real time. This is potentially misleading, particularly on an MP system. If I have 4 cores running on a HZ=100 kernel I expect ~400 clock interrupts per second. But

Re: timeout(9): add clock-based timeouts (attempt 2)

2020-09-07 Thread Scott Cheloha
On Sat, Sep 05, 2020 at 01:11:59PM +0200, Mark Kettenis wrote: > > Date: Fri, 4 Sep 2020 17:55:39 -0500 > > From: Scott Cheloha > > > > On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: > > > > > > [...] > > > > > > I

Re: amd64: add tsc_delay(), a TSC-based delay(9) implementation

2020-09-05 Thread Scott Cheloha
On Tue, Aug 25, 2020 at 12:22:19PM -0700, Mike Larkin wrote: > On Tue, Aug 25, 2020 at 12:12:36PM -0700, Mike Larkin wrote: > > On Mon, Aug 24, 2020 at 01:55:45AM +0200, Mark Kettenis wrote: > > > > Date: Sun, 23 Aug 2020 18:11:12 -0500 > > > > From:

Re: timeout(9): add clock-based timeouts (attempt 2)

2020-09-04 Thread Scott Cheloha
On Fri, Sep 04, 2020 at 05:55:40PM -0500, Scott Cheloha wrote: > On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: > > > > [...] > > > > I want to add clock-based timeouts to the kernel because tick-based > > timeouts suffer from a few problems:

Re: timeout(9): add clock-based timeouts (attempt 2)

2020-09-04 Thread Scott Cheloha
On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: > > [...] > > I want to add clock-based timeouts to the kernel because tick-based > timeouts suffer from a few problems: > > [...] > > Basically, ticks are a poor approximation for the system clock. We

Re: amd64: calibrate lapic timer frequency in constant time

2020-09-01 Thread Scott Cheloha
On Tue, Sep 01, 2020 at 06:14:05PM +0200, Mark Kettenis wrote: > > Date: Tue, 1 Sep 2020 11:05:26 -0500 > > From: Scott Cheloha > > > > Hi, > > > > At boot, if we don't know the lapic frequency offhand we compute it by > > waiting for a known clock (

amd64: calibrate lapic timer frequency in constant time

2020-09-01 Thread Scott Cheloha
Hi, At boot, if we don't know the lapic frequency offhand we compute it by waiting for a known clock (the i8254) with a known frequency to cycle a few times. Currently we cycle hz times. This doesn't make sense. There is little to no benefit to waiting additional cycles if your kernel is

Re: getitimer(2), setitimer(2): merge critical sections

2020-09-01 Thread Scott Cheloha
On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote: > > [...] Two week bump. In summary: - Merge the critical sections so that "timer swap" with setitimer(2) is atomic. - To do this, move error-free operations into a common kernel subroutine, setitimer().

  1   2   3   4   5   6   >