Home
last modified time | relevance | path

Searched hist:e4c9cba71ff03f0aa6daa924437208b29cffeb40 (Results 1 – 3 of 3) sorted by relevance

/freebsd/sys/cam/
H A Dcam_iosched.hdiff e4c9cba71ff03f0aa6daa924437208b29cffeb40 Fri Aug 25 00:10:58 CEST 2017 Warner Losh <imp@FreeBSD.org> Fix 32-bit overflow on latency measurements

o Allow I/O scheduler to gather times on 32-bit systems. We do this by shifting
the sbintime_t over by 8 bits and truncating to 32-bits. This gives us 8.24
time. This is sufficient both in range (256 seconds is about 128x what current
users need) and precision (60ns easily meets the 1ms smallest bucket size
measurements). 64-bit systems are unchanged. Centralize all the time math so
it's easy to tweak tha range / precision tradeoffs in the future.
o While I'm here, the I/O scheduler should be using periph_data rather than
sim_data since it is operating on behalf of the periph.

Differential Review: https://reviews.freebsd.org/D12119
H A Dcam_iosched.cdiff e4c9cba71ff03f0aa6daa924437208b29cffeb40 Fri Aug 25 00:10:58 CEST 2017 Warner Losh <imp@FreeBSD.org> Fix 32-bit overflow on latency measurements

o Allow I/O scheduler to gather times on 32-bit systems. We do this by shifting
the sbintime_t over by 8 bits and truncating to 32-bits. This gives us 8.24
time. This is sufficient both in range (256 seconds is about 128x what current
users need) and precision (60ns easily meets the 1ms smallest bucket size
measurements). 64-bit systems are unchanged. Centralize all the time math so
it's easy to tweak tha range / precision tradeoffs in the future.
o While I'm here, the I/O scheduler should be using periph_data rather than
sim_data since it is operating on behalf of the periph.

Differential Review: https://reviews.freebsd.org/D12119
H A Dcam_xpt.cdiff e4c9cba71ff03f0aa6daa924437208b29cffeb40 Fri Aug 25 00:10:58 CEST 2017 Warner Losh <imp@FreeBSD.org> Fix 32-bit overflow on latency measurements

o Allow I/O scheduler to gather times on 32-bit systems. We do this by shifting
the sbintime_t over by 8 bits and truncating to 32-bits. This gives us 8.24
time. This is sufficient both in range (256 seconds is about 128x what current
users need) and precision (60ns easily meets the 1ms smallest bucket size
measurements). 64-bit systems are unchanged. Centralize all the time math so
it's easy to tweak tha range / precision tradeoffs in the future.
o While I'm here, the I/O scheduler should be using periph_data rather than
sim_data since it is operating on behalf of the periph.

Differential Review: https://reviews.freebsd.org/D12119