You are not logged in.

#1 2013-07-21 18:12:21

Aestus
Member
Registered: 2013-07-18
Posts: 52

[solved] Tuning/Eliminating udev

I've been on a performance-boosting spree, and was wondering if there is a simple way to effectively tune udev or, if not, disable it and set up a static system.  It's been hard to find any info at all on this, but what I know so far is:

  • Udev makes device nodes, loads modules, and responds to hardware changes.
    My kernel has all its modules built in, and my netbook does not change save for unplugging the A/C or, very rarely, inserting a thumb drive.  Nothing else.

  • According to Bootchart, udev uses something on the order of 30% of the CPU and 80% of the I/O during boot.
    That's ugly.

Part of the reason for doing this is education, and part of it is a desire for minimalism and speed, even if it pushes at the bounds of inconvenience.  Udev seems possibly too complex and unwieldy for what I'm trying to achieve, but it's all anyone writes about.

When I say "tune udev, " I mean, "implement a static system via udev."  AFAIK the extra features are unneeded in this case.

Last edited by Aestus (2013-07-21 20:19:08)

Offline

#2 2013-07-21 18:23:12

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: [solved] Tuning/Eliminating udev

No, udev does not make device nodes anymore. It loads modules, but only in response to the kernel sending uevents. You can load modules yourself, but you'll be doing so in serial. udev has multiple threads (workers) which can load modules in parallel. Compiling modules into the kernel will only serve to extend your kernel boot time before the handoff to userspace.

I suggest you look elsewhere.

Offline

#3 2013-07-21 18:24:16

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [solved] Tuning/Eliminating udev

Aestus wrote:

Udev makes device nodes

No, it doesn't smile, devtmpfs does. But udev does load modules and inform userspace of hardware changes.

Now getting rid of udev... before the switch to systemd, it was very much possible, with certain loss of functionality of course (X input hotplugging, udisks and upower, ...). But now with systemd, idk. Can systemd function without udev?

Offline

#4 2013-07-21 18:30:53

Aestus
Member
Registered: 2013-07-18
Posts: 52

Re: [solved] Tuning/Eliminating udev

falconindy wrote:

Compiling modules into the kernel will only serve to extend your kernel boot time before the handoff to userspace.

How so?  I've gone through the kernel config and stripped out everything not needed for my setup to run, using localmodconfig and a good deal of manual editing.  Are you referring to a kitchen-sink kernel?

EDIT:  Also, knowing now that udev does not manage the /dev nodes... wouldn't this mean udev serves no function on my system?  Why then does it hog resources?  It's the biggest thing on bootchart, besides X.  The I/O dwarfs anything else by orders of magnitude.

Last edited by Aestus (2013-07-21 18:34:55)

Offline

#5 2013-07-21 18:49:49

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: [solved] Tuning/Eliminating udev

Aestus wrote:
falconindy wrote:

Compiling modules into the kernel will only serve to extend your kernel boot time before the handoff to userspace.

How so?  I've gone through the kernel config and stripped out everything not needed for my setup to run, using localmodconfig and a good deal of manual editing.  Are you referring to a kitchen-sink kernel?

No, I'm referring to fact that the kernel will run the init code for all linked in modules before handing off control to userspace (the initramfs or PID 1), regardless of if or when the functionality provided by the modules is ever needed. Leaving your kernel modular lets userspace load the modules on an as-needed basis, and asynchronously with other bootstrap tasks.

The I/O dwarfs anything else by orders of magnitude.

This alone is not reason enough to claim that udev is inefficient or point to it as being a bottleneck.

Last edited by falconindy (2013-07-21 18:50:46)

Offline

#6 2013-07-21 18:55:56

Aestus
Member
Registered: 2013-07-18
Posts: 52

Re: [solved] Tuning/Eliminating udev

...Not what I'm claiming.  Just wondering why it registers the way it does, with apparently nothing to do.  More to the point, I'm just trying to figure out if it CAN be removed, regardless of motive.  Following that rationale has proven a great way to learn about Linux in more depth.  If this is an inappropriate question in some way, I apologize.

Offline

#7 2013-07-21 20:10:44

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: [solved] Tuning/Eliminating udev

Aestus wrote:

...Not what I'm claiming.  Just wondering why it registers the way it does, with apparently nothing to do.

Speaking in relative terms (and even that gives your description too much credit) with no basis to compare against is useless. I also question the validity of your statement that udev has "apparently nothing to do."

Aestus wrote:

More to the point, I'm just trying to figure out if it CAN be removed, regardless of motive.

You can probably run 'systemctl mask systemd-udevd.socket' and see what life is like without udev. Things will very likely fail. You may not cleanly make it to a login prompt (systemd may wait for devices that never show up, as it expects to know the status via udev). You'll be missing ACLs on device nodes. Network devices may no longer have sysctl settings applied....

Offline

#8 2013-07-21 20:13:09

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,848

Re: [solved] Tuning/Eliminating udev

there are alternatives for udev, eudev is a fork by gentoo developers and mdev is another option.

However , arch current init system , systemd, depends on udev and afaik won't work with those alternatives.

In short, replacing udev will very likely also mean changing the init system.

I think forum user artoo has experimented with a combination of eudev and openrc, you could try asking him.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#9 2013-07-21 20:18:39

Aestus
Member
Registered: 2013-07-18
Posts: 52

Re: [solved] Tuning/Eliminating udev

Thanks, Lone_Wolf.

Offline

#10 2013-07-21 23:55:42

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [solved] Tuning/Eliminating udev

It doesn't make sense to use eudev, it doesn't offer anything over regular udev.

If you want to go really minimal, go mdev with a non-systemd init, provided that you can deal with not having all the stuff I mentioned before among other things.

Offline

#11 2013-07-22 01:30:06

fhdrin
Member
Registered: 2012-05-10
Posts: 26

Re: [solved] Tuning/Eliminating udev

Offline

#12 2013-07-22 01:55:59

Aestus
Member
Registered: 2013-07-18
Posts: 52

Re: [solved] Tuning/Eliminating udev

Chromium, radeon, and Thunar are all dependent on systemd...  I guess I'll have to look into tuning after all.  Thanks for the suggestions, everyone.  If only there was a way to just drastically cut udev's resource usage at boot without hours of work.

Last edited by Aestus (2013-07-22 01:56:21)

Offline

#13 2013-07-22 02:54:26

simongmzlj
Member
From: Canada
Registered: 2008-11-06
Posts: 135

Re: [solved] Tuning/Eliminating udev

So your assessment that udev needs tuning is because its taking 30% of the CPU and 80% of the I/O during boot. 30% and 80% of what? Precents are useless without a refence. 80% of I/O durring boot could still be either a miniscule or a gigantic amount.

Not to mention that high IO/CPU usage doesn't mean waste, it means efficiency! You want your machine to boot fast? Load everything at once! Loading the same about of data at half the rate is obviously going to be slower.

But whats more important here is udev is dynamically loading functionality as its demanded, but its functionality your operating system needs to preform its job. Removing udev or lightening udev's load isn't going to make you boot faster, its just going to move the work to a different part of the boot process.

Last edited by simongmzlj (2013-07-22 03:09:53)

Offline

#14 2013-07-22 03:39:40

Aestus
Member
Registered: 2013-07-18
Posts: 52

Re: [solved] Tuning/Eliminating udev

Thanks!  And thanks for humoring my relative noobness.  I get what you're saying now.  This is mostly for fun and learning, so it's not desperately important; I just assumed that you could have the device nodes unchanging, modules built-in, and if the setup's simple enough it's work, but that's become ridiculously complicated.  Thanks for bringing me one step closer to having a clue, and here's my bootchart, if you're interested and like painfully small print: http://oi42.tinypic.com/2ho8qcy.jpg

Offline

#15 2013-07-22 04:58:58

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved] Tuning/Eliminating udev

If you use SysV instead, this is much more possible.  Maybe instead of tearing down in order to learn, you should try building up from the bottom.  I think that going through the Linux From Scratch instructions might be of great interest to you.  It will give you a good idea of what each different package does and how they fit together to create a working system.

Offline

#16 2013-07-22 05:37:07

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [solved] Tuning/Eliminating udev

Aestus wrote:

bootchart

For a faster bootup (which, it seems, is what you really want), try e.g. e4rat.

Offline

#17 2013-07-22 06:56:21

Aestus
Member
Registered: 2013-07-18
Posts: 52

Re: [solved] Tuning/Eliminating udev

E4rat only ever functioned once; it ended up slowing down the boot far more than anything else ever did.  Preload, readahead, and Ulatencyd all had that same effect...  I think I'll look at those instructions.  Thanks, everyone.

Offline

#18 2013-07-22 10:03:03

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [solved] Tuning/Eliminating udev

Aestus wrote:

Chromium, radeon, and Thunar are all dependent on systemd...

They arent't, they depend on udev. It's just that Arch packages systemd and udev together, because that's how upstream ships it. But it's possible to compile and install just udev. Gentoo does that. LFS does too, except LFS does it by providing a custom Makefile to build just udev out of the combined systemd+udev tarball.

Offline

#19 2013-07-22 11:13:50

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,422
Website

Re: [solved] Tuning/Eliminating udev

FWIW, on one of my systems e4rat works wonders, on the other it did seem to slow it down slightly.  However, when I disabled it, I found boot up was faster than before I had initially installed e4rat.  I suspect this means the reallocation process itself was a benefit on that system even if the preloading service was not.  You might want to see if some such mix-and-match will benefit you.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB