XXXX pvscsi needs some love
Review Request #633 — Created July 20, 2017 and discarded — Latest diff uploaded
Information | |
---|---|
yuripv | |
illumos-gate | |
master | |
Reviewers | |
general | |
An attempt to solve several issues that have been annoying me for some time,
namely double panics when saving the dump (related to bus reset/command aborts),
panics when constantly inquiring the targets on bus configs, and simple some
cleanup:
- don't abort commands before resetting the bus (called from sddump), leading
to processing already freed ones - rework the command abort path - follow what linux does, and sleep for a bit of
time waiting for command abort to be acknowledged by HBA - cleanup the poll code path
- rework comp ring processing - only check the completion ring in interrupt,
leaving everything else to be done using the taskq; complete commands as we
get them from the ring, without chaining them and processing later - this
came with initial driver version, and I don't have any idea why it was done
as it doesn't show any performance gains (which is exactly what could be
expected) - rework msg ring processing (triggered by Robert's questions) - only check
the message ring in interrupt handler, leaving everything else to be done
using the taskq; this way we won't ever miss a notification - if taskq
dispatch fails, the message ring is left untouched - introduce a static "target map" instead of dynamically allocated one, don't
do inquiry every time when the bus config happens, and instead rely on target
map to report if target is already attached, as it can't simply disappear
without a notification (virtual hardware is a "perfect world", or should be)
All done using the disks connected via this driver, or on a pool on top of them:
- zfs-tests run
- full nightly build
- continuos vdbench runs
- bulk add/remove the disks (under the load as well)