In the original clockintr(9) proposal, Scott mentioned allowing
timeout(9) to steer the clock interrupt so userspace could block
for less than one tick, specifically noting vmm/vmd timing
problems.
Is that still the intended direction for timeout(9), or was there
a technical problem with that design that prevented it from being
implemented?
I am debugging the i8253 emulation in -current and found that vmd
guests that programs PIT channel 0 for deadlines between roughly
0.1 and 10ms receives IRQ0 around 17-20ms later.
Diagnostics from 9front show, for example:
- requested PIT divisor avg: 2743 (~2.3ms)
- maximum requested: 11927 (10.0ms)
- actual IRQ0 average: 17.44ms
- 80% of IRQs: >18ms
The path appears to be:
kevent_timeout
->msleep_nsec
->timeout_add_nsec
->hardclock/tick resolution
I would like to work on fixing this, but before writing a diff, I
want to know whether making clock-based timeouts steer clockintr
is still the preferred architecture, and whether there are issues
that stopped the earlier work.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.