On Thu, Nov 8, 2018 at 10:07 AM Alexander Duyck <[email protected]> wrote: > > Probe devices asynchronously instead of the driver. This results in us > seeing the same behavior if the device is registered before the driver or > after. This way we can avoid serializing the initialization should the > driver not be loaded until after the devices have already been added. > > The motivation behind this is that if we have a set of devices that > take a significant amount of time to load we can greatly reduce the time to > load by processing them in parallel instead of one at a time. In addition, > each device can exist on a different node so placing a single thread on one > CPU to initialize all of the devices for a given driver can result in poor > performance on a system with multiple nodes.
Do you have numbers on effects of this change individually? Is this change necessary for the libnvdimm init speedup, or is it independent? > I am using the driver_data member of the device struct to store the driver > pointer while we wait on the deferred probe call. This should be safe to do > as the value will either be set to NULL on a failed probe or driver load > followed by unload, or the driver value itself will be set on a successful > driver load. In addition I have used the async_probe flag to add additional > protection as it will be cleared if someone overwrites the driver_data > member as a part of loading the driver. I would not put it past a device-driver to call dev_get_drvdata() before dev_set_drvdata(), to check "has this device already been initialized". So I don't think it is safe to assume that the core can stash this information in ->driver_data. Why not put this infrastructure in struct device_private? _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
