[RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()

[RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()

[Stefan Roese]

I've noticed that the first ext4 file loading from a MMC partition for
ZynqMP takes quite some time (~ 1 second). Debugging showed, that the
MMC driver reads the partition info 128 time (MAX_SEARCH_PARTITIONS)
resulting in this boot delay. To fix this, let's just end creating the
block drives in part_create_block_devices() when no more valid partition
is found. This reduces the first file reading from ~0.9s to ~0.3s.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
Reasoning for RFC:
I did not dig into the current disk / partition stuff too deeply, so I'm
not 100% sure that this patch does not break anything.
---
 disk/disk-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
index d32747e2242d..2999f7285b5a 100644
--- a/disk/disk-uclass.c
+++ b/disk/disk-uclass.c
@@ -36,7 +36,7 @@ int part_create_block_devices(struct udevice *blk_dev)
 	/* Add devices for each partition */
 	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
 		if (part_get_info(desc, part, &info))
-			continue;
+			break;
 		snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
 			 part);
 
-- 
2.39.0

Re: [RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()

[AKASHI Takahiro]

Hi,

Thank you for catching this issue.

On Tue, Jan 10, 2023 at 09:00:38AM +0100, Stefan Roese wrote:
> I've noticed that the first ext4 file loading from a MMC partition for
> ZynqMP takes quite some time (~ 1 second). Debugging showed, that the
> MMC driver reads the partition info 128 time (MAX_SEARCH_PARTITIONS)
> resulting in this boot delay. To fix this, let's just end creating the
> block drives in part_create_block_devices() when no more valid partition
> is found. This reduces the first file reading from ~0.9s to ~0.3s.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> Reasoning for RFC:
> I did not dig into the current disk / partition stuff too deeply, so I'm
> not 100% sure that this patch does not break anything.

I'm afraid that this fix won't work for all the partition types,
especially for those in which entries in a partition table can be sparsely filled,
or in other words, valid partition numbers may not always be contiguous
even if they don't reach a maximum number.

I somehow confirmed this against a GPT partition by using gdisk.

-Takahiro Akashi

> ---
>  disk/disk-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
> index d32747e2242d..2999f7285b5a 100644
> --- a/disk/disk-uclass.c
> +++ b/disk/disk-uclass.c
> @@ -36,7 +36,7 @@ int part_create_block_devices(struct udevice *blk_dev)
>  	/* Add devices for each partition */
>  	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
>  		if (part_get_info(desc, part, &info))
> -			continue;
> +			break;
>  		snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
>  			 part);
>  
> -- 
> 2.39.0
> 

Re: [RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()

[Stefan Roese]

On 1/11/23 02:32, AKASHI Takahiro wrote:
> Hi,
> 
> Thank you for catching this issue.
> 
> On Tue, Jan 10, 2023 at 09:00:38AM +0100, Stefan Roese wrote:
>> I've noticed that the first ext4 file loading from a MMC partition for
>> ZynqMP takes quite some time (~ 1 second). Debugging showed, that the
>> MMC driver reads the partition info 128 time (MAX_SEARCH_PARTITIONS)
>> resulting in this boot delay. To fix this, let's just end creating the
>> block drives in part_create_block_devices() when no more valid partition
>> is found. This reduces the first file reading from ~0.9s to ~0.3s.
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Cc: Simon Glass <sjg@chromium.org>
>> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> ---
>> Reasoning for RFC:
>> I did not dig into the current disk / partition stuff too deeply, so I'm
>> not 100% sure that this patch does not break anything.
> 
> I'm afraid that this fix won't work for all the partition types,
> especially for those in which entries in a partition table can be sparsely filled,
> or in other words, valid partition numbers may not always be contiguous
> even if they don't reach a maximum number.

So what is the maximum number? Where originates the
MAX_SEARCH_PARTITIONS = 128 from?

> I somehow confirmed this against a GPT partition by using gdisk.

How exactly did you confirm this?

Thanks,
Stefan

> -Takahiro Akashi
> 
>> ---
>>   disk/disk-uclass.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
>> index d32747e2242d..2999f7285b5a 100644
>> --- a/disk/disk-uclass.c
>> +++ b/disk/disk-uclass.c
>> @@ -36,7 +36,7 @@ int part_create_block_devices(struct udevice *blk_dev)
>>   	/* Add devices for each partition */
>>   	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
>>   		if (part_get_info(desc, part, &info))
>> -			continue;
>> +			break;
>>   		snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
>>   			 part);
>>   
>> -- 
>> 2.39.0
>>

Viele Grüße,
Stefan Roese

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()

[AKASHI Takahiro]

On Wed, Jan 11, 2023 at 09:05:05AM +0100, Stefan Roese wrote:
> On 1/11/23 02:32, AKASHI Takahiro wrote:
> > Hi,
> > 
> > Thank you for catching this issue.
> > 
> > On Tue, Jan 10, 2023 at 09:00:38AM +0100, Stefan Roese wrote:
> > > I've noticed that the first ext4 file loading from a MMC partition for
> > > ZynqMP takes quite some time (~ 1 second). Debugging showed, that the
> > > MMC driver reads the partition info 128 time (MAX_SEARCH_PARTITIONS)
> > > resulting in this boot delay. To fix this, let's just end creating the
> > > block drives in part_create_block_devices() when no more valid partition
> > > is found. This reduces the first file reading from ~0.9s to ~0.3s.
> > > 
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > Cc: Simon Glass <sjg@chromium.org>
> > > Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > > ---
> > > Reasoning for RFC:
> > > I did not dig into the current disk / partition stuff too deeply, so I'm
> > > not 100% sure that this patch does not break anything.
> > 
> > I'm afraid that this fix won't work for all the partition types,
> > especially for those in which entries in a partition table can be sparsely filled,
> > or in other words, valid partition numbers may not always be contiguous
> > even if they don't reach a maximum number.
> 
> So what is the maximum number? Where originates the
> MAX_SEARCH_PARTITIONS = 128 from?

commit bc314f8e5f9b ("cmd: part: list all 128 GPT partitions")

But GPT may accept arbitrary number of partitions.
The GPT header has "num_partition_entries" for the table size.

The max depends on partition types.

> > I somehow confirmed this against a GPT partition by using gdisk.
> 
> How exactly did you confirm this?

Created partitions for, say, #3 and #5 by 'n' command.

-Takahiro Akashi

> Thanks,
> Stefan
> 
> > -Takahiro Akashi
> > 
> > > ---
> > >   disk/disk-uclass.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
> > > index d32747e2242d..2999f7285b5a 100644
> > > --- a/disk/disk-uclass.c
> > > +++ b/disk/disk-uclass.c
> > > @@ -36,7 +36,7 @@ int part_create_block_devices(struct udevice *blk_dev)
> > >   	/* Add devices for each partition */
> > >   	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> > >   		if (part_get_info(desc, part, &info))
> > > -			continue;
> > > +			break;
> > >   		snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
> > >   			 part);
> > > -- 
> > > 2.39.0
> > > 
> 
> Viele Grüße,
> Stefan Roese
> 
> -- 
> DENX Software Engineering GmbH,      Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de