Re: [PATCH v2] wait while adding MMC host to ensure root mounts

[Ulf Hansson]

On 27 March 2013 13:28, ÐÐÑÐÐÐ ÐÐÐÐÐÑ <ynvich@xxxxxxxxx> wrote:
> Hi Ulf,
>
> On 27 March 2013 15:13, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>> Moreover, this patch will have bad impact on booting the kernel, since
>> every host device that has scheduled a detect work from it's probe
>> function will also wait for it to finish. Even if it is the boot
>> device of not. If this is needed, I would prefer that a host cap is
>> used.
>
> Do you have any profiling data supporting bad impact on boot?
>
> It should be it in the range of dozens us, if any. Without the patch,
> approx. 30% of boots succeeded with CONFIG_PREEMT and aprox. 95%
> without CONFIG_PREEMT. mmc_rescan is just a few instructions, if there
> is no card present. On boot and with a card present, it might only
> sleep in the host implementation.
>
> Anyway, something had to be done about mmc boot. rootdelay will not
> report error if the card is absent or its partition table is damaged.
> rootdelay is a workaround by definition, so it may occasionally fail
> if it is too small. Big rootdealy has a clear bad impact on boot time.

Consider a platform having two eMMCs and one SD-card. Each eMMC card
will take around 400 ms to initialize and the SD-card 700 ms. The card
initialization times are real examples from eMMCs and SD-cards,
moreover those are typical values not worth cases. In total we have
around 1.5 s to initialize the cards.

Now, suppose you boot using an initrd image. Thus neither of the cards
needs to be accessible immediately after the kernel has booted. It all
depends what the init process decides to do. With this patch the init
process will always be delayed to wait for each and every card to be
initialized. I would prefer a solution where this can be configurable
somehow, since certainly this is not the scenario you want for all
cases.

Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/