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
> 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.
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:
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
>
>
> 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
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
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
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:
> > > >
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
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
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
> 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.
>>
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
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
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
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
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
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
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.
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 */
>
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
> > > &
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
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
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
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
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)
{
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
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
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.
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
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
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
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:
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
> >
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
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.
&
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
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
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
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.
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
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
> 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
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
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)
> 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
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
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
>
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
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
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
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
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,
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
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
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
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
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
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
> >
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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() 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
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:
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) 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
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
> 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
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
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
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
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)
&
`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
> 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
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.
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
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
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
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
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:
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:
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
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 (
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
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 - 100 of 506 matches
Mail list logo
