Re: Fixing excessive shootdowns during FFS read (kern/53124) on x86

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

2018-03-27 0:51 GMT+02:00 Michael van Elst <mlelstv%serpens.de@localhost>:
> UBC_WINSHIFT=17 (i.e. 2*MAXPHYS) works fine, but sure, for KVA limited
> platforms you have to be careful. On the other hand, it's a temporary
> mapping that only exists while doing I/O. How many concurrent I/O
> operations would you expect on a 32bit system?

I think fragmentation might be bigger issue. It could happen there just
won't be continuous 128k KVA block any more, then it would hang
forever, like kern/47030. But maybe this is not concern, e.g. i386 KVA
uses top 1G.

> I'd also like to get another tuning to 8.0. Bumping RA_WINWIZE_MAX
> from 8*MAXPHYS to 16*MAXPHYS helps iSCSI and maybe some nvme devices
> too.

Yes please :) For some reason I thought we have this already. I remember this
mentioned in discussion around time nvme(4) got integrated into tree.

Regarding your issue, I'd also like to turn attention back to the acpi idle too.
The way I read dev/acpi/acpi_cpu_cstate.c, we try to go straight to C3
without any
backoff. It maybe be good to make this more granular, maybe only going
into the deeper states once enough idle time passes, for example longer
time then their wakeup latency.

For example, wakeup from C1 might have 1 usec latency, from C2 has 150 usec
latency, from C3 500.

Any opinion on that, any ACPI experts around?

Jaromir