On 10/18/2018 10:15 AM, Greg KH wrote:
On Thu, Oct 18, 2018 at 09:51:03AM -0700, Alexander Duyck wrote:
On 10/18/2018 9:46 AM, Bart Van Assche wrote:
On Thu, 2018-10-18 at 08:25 -0700, Alexander Duyck wrote:
On 10/17/2018 5:54 PM, Dan Williams wrote:
On Wed, Oct 17, 2018 at 4:41 PM Bart Van Assche <bvanass...@acm.org> wrote:

Instead of probing devices sequentially in the PROBE_PREFER_ASYNCHRONOUS
mode, scan devices concurrently. This helps when the wall clock time for
a single probe is significantly above the CPU time needed for a single
probe, e.g. when scanning SCSI LUNs over a storage network.

Alex had a similar patch here [1] that I don't think has been accepted
yet, in any event some collaboration is needed:

[1]: https://lkml.org/lkml/2018/9/27/14

The patch set referenced is a little out of date. The latest set is:
https://lore.kernel.org/lkml/20181015150305.29520.86363.stgit@localhost.localdomain/

I'm also not quite sure what the point of this patch is. I don't think
it is doing what it says it is doing. From what I can tell it is just
allowing the driver init code to ignore if the driver wants to be probed
asynchronously or not. Further comments inline below.

Hi Alexander,

Thanks for the pointer to the latest version of your patch series. I was not
yet aware of your work when I posted this patch series. Now that I have had a
look at your patch series I like your approach better than what I did in this
patch. Since it could take a while before agreement is reached about the async
domain patches in the same patch series, how about you submitting patches 3/6
and 4/6 from your patch series to Greg for kernel version v4.20? If I drop
the driver core patches from my patch series and replace these with your
driver core patches I achieve the same results. If you Cc me when you resubmit
these patches I will review them.

Thanks,

Bart.

Actually the async and workqueue patches have already been reviewed and last
I knew they were okay with the workqueue guys. These patches are already
submitted to Greg for 4.20.

It's too late for 4.20 now, sorry.  They will have to wait.  Given that
4.19-final could have come out last weekend, this shouldn't be a
supprise.

They are in my review queue and I'll get to them after 4.20-rc1 is out.

thanks,

greg k-h

Well I was hoping for 4.20 anyway. :-/

Thanks for letting me know.

- Alex

Reply via email to