This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is "udev" causing a slow boot?

My boot process takes a long time right after "Starting udev" is printed on the console.  My question is...

- can I speed up the boot process by reducing the amount of things that udev does?

The /dev/udev/rules.d directory has a lot of files that if I understand correctly tell udev what sort of processing to perform.  It seems that I have way more device files than I need for an embedded codec, so I'm wondering has anyone dealt with speeding up the boot process by paring down the rules.

Any help or advice is appreciated.

John A

  • udev is a part of it,  Here's some slides titled '1 second boot', pretty interesting work:

    http://www.slideshare.net/andrewmurraympc/elce-the

     

    Cheers,

    Mitch

  • The slideshare is missing.  Can't find it on googling.  swiftboot.com has incorrect contact info.  http://www.mpc-data.co.uk/about-us-contact-us/ has CORRECT CONTACT INFO for consulting services.  http://www.bsquare.com/ is how they answer the phone.

    TOO EXPENSIVE FOR ME.  Does anybody have an archive or saved copy of these slides?

  • Hi ,

    You can refer this page for boot time optimization

    http://processors.wiki.ti.com/index.php/Optimize_Linux_Boot_Time

    Regards

    AnilKumar

    Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

  • Anil,

    Thanks very much for this advice.  I have read through the Optimize_Linux_Boot_Time and will try to use it in the future when it's applicable.

    However, it's focusing on seconds, and my problem right now is over an order of magnitude larger.  The link doesn't address the two primary places where I have big delays:

    1) 25 seconds mounting jffs2 on nand, and

    2) 21 seconds "Starting udev" and "Populating dev cache".

    This 46 seconds represents 69% of my 67 second time from "Starting kernel" and uncompress to default app startup (/etc/rc5.d/S99...).

    I've searched elsewhere and have ideas about checking nand chip speed, reducing file system size, reducing device count, and using mknod instead of udev.  However, I'm really a newbee at all this kernel stuff and don't have a clue as to how to do any of those things.

    Any additional advice would be greatly appreciated.  I would LOVE to read a DM6467-centric treatise on the two items above.

  • ...meanwhile, John Anderson, I don't have a "/dev/udev" folder at all????  Did you ever get a resolution to your original question?  Thx.

    EDIT: Oh, I do find a "/etc/udev/rules.d" folder.  Nevertheless, did you get a resolution?

  • No resolution. Our boot time is about 45 sec.  We got quite a bit of speedup from using a faster SD card.  Looks like the udev portion is about 15sec.

    JohnA

  • Thx.  Posted elsewhere:

    1) 25 seconds mounting jffs2 on nand, and

    2) 21 seconds "Starting udev" and "Populating dev cache".

    This 46 seconds represents 69% of my 67 second time from "Starting kernel" and uncompress to default app startup (/etc/rc5.d/S99...).

    I've searched elsewhere and have ideas about checking nand chip speed, reducing file system size, reducing device count, and using mknod instead of udev.  However, I'm really a newbee at all this kernel stuff and don't have a clue as to how to do any of those things. 

  • Hi Helmut,

    Why don't you try using UBIFS instead of JFFS2? If you are particular about using JFFS2 you have to optimize the NAND throughput to reduce the boot time. At PathPartner we've a team specialized in boot up time optimization and storage driver throughput improvement. We've achieved amazing boot times in couple of TI platforms like DM36x, OMAP4, DM814x etc. We've achieved realistic boot time reduction by optimizing the storage driver throughput etc.. 

    Regards,
    Renjith Thomas

    Senior Technical Leader

    PathPartner Technology Consulting.