Re: [PATCH 1/2] MTD: UBI: speed up init by moving status messages to debugfs

[Richard Weinberger <richard@nod.at>]

Rajeev,

Am 25.07.2016 um 13:23 schrieb Rajeev Kumar:
> Richard
> 
> On 07/25/2016 04:01 PM, Richard Weinberger wrote:
>> Rajeev,
>>
>> Am 25.07.2016 um 11:46 schrieb Rajeev Kumar:
>>> This patch simply moves the verbose status messages associated with
>>> UBI's fastmap feature to debugfs, thereby decreasing UBI
>>> initialization time from 97 mS to 16 mS. Note that the first time
>>> fastmap is invoked, building the fastmap took 146 mS. In order to
>>> reproduce the test conditions, build with CONFIG_MTD_UBI_FASTMAP=y and
>>> CONFIG_DYNAMIC_DEBUG=y and append the following to bootargs:
>>>
>>> initcall_debug ubi.mtd=0 ubi.fm_autoconvert=1
>>>
>>> ubi.mtd=0 is needed at every boot if you want ubi to be
>>> autoloaded. ubi.fm_autoconvert switch is needed only once, when
>>> fastmap is created.
>>
>> So, you're working on a system which has to boot as fast as possible
>> and writing kernel logs hurts the performance. (Slow UART?)
>> Why do you change logging only in UBI (Fastmap)? Many other subsystems
>> print during boot and would also hurt the performance.
>> In such a situation I'd assume that changing the kernel log level or
>> using the quiet kernel parameter would help more.
>>
> 
> Agreed, but the question is do we really need these all values for UBI(Fastmap) on console every time system is booted ?

These days I'd not print all of them. But we do already and I know setups which parse dmesg and grep for some of these
values. Either to see whether attach worked or just to gather debug infos for QA.
I don't want to risk breaking existing stuff.
Since your problem can be solved perfectly fine by using loglevels I think it is better to stay on the
safe side and keep them as-is.

Thanks,
//richard