Bug 258295 - nvme initialization may be unnecessarily slow
Summary: nvme initialization may be unnecessarily slow
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Warner Losh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-05 22:02 UTC by Colin Percival
Modified: 2021-09-07 19:46 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Colin Percival freebsd_committer freebsd_triage 2021-09-05 22:02:25 UTC
Initialization of nvme(4) devices includes two 100 ms pause(9) calls while resetting the devices, along with a number of shorter delays; on EC2, about 335 ms is spent in nvme_ctrlr_start_config_hook.

Linux recently replaced a 100 ms wait with 1 ms waits plus polling the device to see if it was ready; it would be nice if we could do something similar, since the time spent in nvme initialization is now a nontrivial proportion of kernel boot time.

https://www.phoronix.com/scan.php?page=news_item&px=NVMe-Faster-Linux-5.7-Boot
Comment 1 Colin Percival freebsd_committer freebsd_triage 2021-09-07 18:24:04 UTC
BTW independent of whether we're pausing for longer than needed, we're currently running these from nvme_ctrlr_start_config_hook which means initializing one nvme device at once; on systems with many disks there would be a large win by having these run in parallel.
Comment 2 Warner Losh freebsd_committer freebsd_triage 2021-09-07 19:46:51 UTC
(In reply to Colin Percival from comment #1)
Yea, we just pushed a formally one at a time process into config_intrhook().
It needs to be reworked to be more of a state machined kicked off from config_intrhook()...