[PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[Michal Clapinski]

Comments in linux/device/driver.h say that the goal is to do async
probing on all devices. The current behavior unnecessarily slows down
the boot by synchronous probing dax_pmem devices, so let's change that.

Signed-off-by: Michal Clapinski <mclapinski@google.com>
---
 drivers/dax/pmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index bee93066a849..737654e8c5e8 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -77,6 +77,7 @@ static struct nd_device_driver dax_pmem_driver = {
 	.probe = dax_pmem_probe,
 	.drv = {
 		.name = "dax_pmem",
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.type = ND_DRIVER_DAX_PMEM,
 };
-- 
2.51.0.618.g983fd99d29-goog

Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[Michał Cłapiński]

ping

On Thu, Oct 2, 2025 at 6:19 AM Michal Clapinski <mclapinski@google.com> wrote:
>
> Comments in linux/device/driver.h say that the goal is to do async
> probing on all devices. The current behavior unnecessarily slows down
> the boot by synchronous probing dax_pmem devices, so let's change that.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
> ---
>  drivers/dax/pmem.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
> index bee93066a849..737654e8c5e8 100644
> --- a/drivers/dax/pmem.c
> +++ b/drivers/dax/pmem.c
> @@ -77,6 +77,7 @@ static struct nd_device_driver dax_pmem_driver = {
>         .probe = dax_pmem_probe,
>         .drv = {
>                 .name = "dax_pmem",
> +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>         },
>         .type = ND_DRIVER_DAX_PMEM,
>  };
> --
> 2.51.0.618.g983fd99d29-goog
>

Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[dan.j.williams]

Michal Clapinski wrote:
> Comments in linux/device/driver.h say that the goal is to do async
> probing on all devices. The current behavior unnecessarily slows down
> the boot by synchronous probing dax_pmem devices, so let's change that.
> 
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
> ---
>  drivers/dax/pmem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
> index bee93066a849..737654e8c5e8 100644
> --- a/drivers/dax/pmem.c
> +++ b/drivers/dax/pmem.c
> @@ -77,6 +77,7 @@ static struct nd_device_driver dax_pmem_driver = {
>  	.probe = dax_pmem_probe,
>  	.drv = {
>  		.name = "dax_pmem",
> +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
>  	},
>  	.type = ND_DRIVER_DAX_PMEM,
>  };

Hi Michal,

Apologies for not commenting earlier. When this first flew by I paused
because libnvdimm predated some of the driver core work on asynchronous
and has some local asynchronous registration.

Can you say a bit more about how this patch in particular helps your
case? For example, the pmem devices registered by memmap= (nd_e820
driver), should end up in the nd_async_device_register() path.

So even though the final attach is synchronous with device arrival, it
should still be async with respect to other device probing.

However, I believe that falls back to synchronous probing if the driver
is loaded after the device has already arrived. Is that the case you are
hitting?

I am ok with this in concept, but if we do this it should be done for
all dax drivers, not just dax_pmem.

Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[Michał Cłapiński]

On Wed, Oct 22, 2025 at 4:38 PM <dan.j.williams@intel.com> wrote:
>
> Michal Clapinski wrote:
> > Comments in linux/device/driver.h say that the goal is to do async
> > probing on all devices. The current behavior unnecessarily slows down
> > the boot by synchronous probing dax_pmem devices, so let's change that.
> >
> > Signed-off-by: Michal Clapinski <mclapinski@google.com>
> > ---
> >  drivers/dax/pmem.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
> > index bee93066a849..737654e8c5e8 100644
> > --- a/drivers/dax/pmem.c
> > +++ b/drivers/dax/pmem.c
> > @@ -77,6 +77,7 @@ static struct nd_device_driver dax_pmem_driver = {
> >       .probe = dax_pmem_probe,
> >       .drv = {
> >               .name = "dax_pmem",
> > +             .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> >       },
> >       .type = ND_DRIVER_DAX_PMEM,
> >  };
>
> Hi Michal,
>
> Apologies for not commenting earlier. When this first flew by I paused
> because libnvdimm predated some of the driver core work on asynchronous
> and has some local asynchronous registration.
>
> Can you say a bit more about how this patch in particular helps your
> case? For example, the pmem devices registered by memmap= (nd_e820
> driver), should end up in the nd_async_device_register() path.
>
> So even though the final attach is synchronous with device arrival, it
> should still be async with respect to other device probing.
>
> However, I believe that falls back to synchronous probing if the driver
> is loaded after the device has already arrived. Is that the case you are
> hitting?

Yes. I use all pmem/devdax modules built into the kernel so loading
them is in the critical path for kernel boot.
I use memmap= with devdax. So first, the pmem device is created
asynchronously, which means loading the nd_e820 module is always fast.
But then, the dax_pmem driver is loaded. If the dax device has not yet
been created by the async code, then loading this module is also fast.
But if the dax device has already been created, then attaching it to
the dax_pmem driver will be synchronous and on the critical boot path.

For thousands of dax devices, this increases the boot time by more
than a second. With the patch it takes ~10ms.

> I am ok with this in concept, but if we do this it should be done for
> all dax drivers, not just dax_pmem.

Will do in v2.

Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[dan.j.williams]

Michał Cłapiński wrote:
[..]
> > However, I believe that falls back to synchronous probing if the driver
> > is loaded after the device has already arrived. Is that the case you are
> > hitting?
> 
> Yes. I use all pmem/devdax modules built into the kernel so loading
> them is in the critical path for kernel boot.
> I use memmap= with devdax. So first, the pmem device is created
> asynchronously, which means loading the nd_e820 module is always fast.
> But then, the dax_pmem driver is loaded. If the dax device has not yet
> been created by the async code, then loading this module is also fast.
> But if the dax device has already been created, then attaching it to
> the dax_pmem driver will be synchronous and on the critical boot path.
> 
> For thousands of dax devices, this increases the boot time by more
> than a second. With the patch it takes ~10ms.
> 
> > I am ok with this in concept, but if we do this it should be done for
> > all dax drivers, not just dax_pmem.
> 
> Will do in v2.

Sounds good, include that detail above and I'll ack / poke Ira to pick
it up.

Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

[Ira Weiny]

dan.j.williams@ wrote:
> Michał Cłapiński wrote:
> [..]
> > > However, I believe that falls back to synchronous probing if the driver
> > > is loaded after the device has already arrived. Is that the case you are
> > > hitting?
> > 
> > Yes. I use all pmem/devdax modules built into the kernel so loading
> > them is in the critical path for kernel boot.
> > I use memmap= with devdax. So first, the pmem device is created
> > asynchronously, which means loading the nd_e820 module is always fast.
> > But then, the dax_pmem driver is loaded. If the dax device has not yet
> > been created by the async code, then loading this module is also fast.
> > But if the dax device has already been created, then attaching it to
> > the dax_pmem driver will be synchronous and on the critical boot path.
> > 
> > For thousands of dax devices, this increases the boot time by more
> > than a second. With the patch it takes ~10ms.
> > 
> > > I am ok with this in concept, but if we do this it should be done for
> > > all dax drivers, not just dax_pmem.
> > 
> > Will do in v2.
> 
> Sounds good, include that detail above and I'll ack / poke Ira to pick
> it up.

Yea if you send to me I'll pick it up.  Sorry I did not see this before.

Ira