[RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()
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);
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;-- 2.39.0
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;-- 2.39.0
Viele Grüße, Stefan Roese
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;-- 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
participants (2)
-
AKASHI Takahiro -
Stefan Roese