[PATCH] nvme: Boot as soon as the boot controller has been probed

[Bart Van Assche]

On 11/11/20 11:19 AM, Keith Busch wrote:
> On Sat, Nov 07, 2020 at 08:09:03PM -0800, Bart Van Assche wrote:
>> The following two issues have been introduced by commit 1811977568e0
>> ("nvme/pci: Use async_schedule for initial reset work"):
>> - The boot process waits until all NVMe controllers have been probed
>>   instead of only waiting until the boot controller has been probed.
>>   This slows down the boot process.
>> - Some of the controller probing work happens asynchronously without
>>   the device core being aware of this.
>>
>> Hence this patch that makes all probing work happen from nvme_probe()
>> and that tells the device core to probe multiple NVMe controllers
>> concurrently by setting PROBE_PREFER_ASYNCHRONOUS.
> 
> I am finding that this setting probes devices in parallel on boot up,
> but serially for devices added after boot. That's making this a rather
> unappealing patch.

Hi Keith,

Thanks for having verified this. However, to me it is unexpected that my
patch results in serial probing of NVMe devices added after boot. It
would be appreciated if more information could be shared about how that
test was run. I'm wondering whether the serialization perhaps was the
result of how the test was run? My understanding of the driver core is
that the decision whether or not to probe concurrently is taken inside
__driver_attach() and also that PROBE_PREFER_ASYNCHRONOUS should trigger
a call of the following code:

		async_schedule_dev(__driver_attach_async_helper, dev);

I expect that calling the above code should result in concurrent probing.

Thanks,

Bart.