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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html