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

2020-09-05 Thread Todd Carson


Scott Cheloha writes:

> 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:
>> > Basically, ticks are a poor approximation for the system clock.  We
>> > should use the real thing where possible.
>> > 
>> > [...]
>> > 
>> > Thoughts on this approach?  Thoughts on the proposed API?
>> 
>> 6 week bump.
>> 

This might not be a very useful data point, but I ran this aggressively
for a couple weeks using clock timeouts for process sleeps, like this:

--- kern/kern_fork.c20 Mar 2020 08:14:07 -  1.225
+++ kern/kern_fork.c26 Jul 2020 09:34:56 -
@@ -166,7 +166,7 @@ thread_new(struct proc *parent, vaddr_t 
/*
 * Initialize the timeouts.
 */
-   timeout_set(>p_sleep_to, endtsleep, p);
+   timeout_set_kclock(>p_sleep_to, endtsleep, p, 0, KCLOCK_UPTIME);
 
return p;
 }

On a VM which has always had a lot of problems with kqueue timers firing
late and causing dovecot to complain "time jumped forward" in syslog,
using the clock timeouts eliminated the complaints and caught a much
larger number of late timeouts in the kern.timeout_stats.

I didn't notice any adverse side effects and I didn't try to measure
performance impact.

> +uint32_t
> +timeout_maskwheel(uint32_t level, const struct timespec *abstime)
> +{
> + uint32_t hi, lo;
> +
> + hi = abstime->tv_sec << 7;
> + lo = abstime->tv_nsec / 7812500;
> +
> + return ((hi | lo) >> (level * WHEELBITS)) & WHEELMASK;
> +}

I found it a little hard to understand at first where 7812500 came from;
would it be too ugly to write it as (10L / (1 << 7))?



Re: sdmmc(4): add UHS-I support

2020-08-17 Thread Todd Carson


Mark Kettenis writes:

>> However, to make sure this diff doesn't break existing lower speed
>> modes I'd appreciate tests on a variety of hardware.  So if sdmmc(4)
>> shows up in your dmesg, please test this by exercising your (u)SD or
>> (e)MMC cards.

No problems encountered reading/writing the SD card with this diff
on RPi4:

sdhc0: SDHC 3.0, 250 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
...
sdhc1 at simplebus4
sdhc1: SDHC 3.0, 100 MHz base clock
sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
...
scsibus0 at sdmmc1: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable
sd0: 15193MB, 512 bytes/sector, 31116288 sectors
...
bwfm0 at sdmmc0 function 1
manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 2 not configured
manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 3 not configured



Re: 11n Tx aggregation for iwm(4)

2020-06-26 Thread Todd Carson


This is from an 8265:

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x88, msi
iwm0: hw rev 0x230, fw ver 34.0.1,

Associated to an Apple AirPort AP on a 5 GHz channel.

Before:
bandwidth min/avg/max/std-dev = 11.402/17.410/36.190/4.079 Mbps

After:
bandwidth min/avg/max/std-dev = 5.147/25.039/54.066/8.489 Mbps

$ netstat -W iwm0 | grep "output block"
1 new output block ack agreement
0 output block ack agreements timed out