Is there another way to improve my laptop performance?

Message

samiswt · Post by **samiswt** » Thu Oct 22, 2015 10:05 pm

Hi guys,

Hardware specs of my laptop is the following:
Intel i3
6GB memory
Intel i915 Video Card

Gentoo kernel is the latest, software specs is the following:
sshd, Xorg-server, awesome, firefox,

I've installed bootchart after kernel compiled and installed. The bootchart png said :

Cumulative I/O usage, by process; total I/O: 25.455s, time: 38.5 s, in particular, systemd-udevd is 15.817 s, Xorg 0.991s, sshd 0.707s

All the suggestions I can have is to replace udev with mdev, my question is if I'd like to have the performance around 15s-20s, what should I do rather than the replacement? How fast could it be if I made the replacement?

I'm on the replacing process right now.

Thank you very much.

davidm · Post by **davidm** » Thu Oct 22, 2015 10:15 pm

Are you really mostly focused on improving boot time though?

For overall performance I would think a SSD hard drive would help quite a bit if you don't already have one. And what kind of i3 is in there? They can range from about like an old core 2 in performance all the way up to pretty good depending on the model of the CPU. That might be a bottleneck there depending on what you have.

I wouldn't expect going to mdev to help too much...

The Doctor · Post by **The Doctor** » Thu Oct 22, 2015 10:19 pm

Mdev is a serous trade off and it probably won't save too much time because it needs to do basically the same job. Static dev would probably be faster, but again trade offs.

If you really want to speed things along, look in /etc/rc.conf and set rc_parallel="YES" after you read the warnings.

samiswt · Post by **samiswt** » Thu Oct 22, 2015 10:35 pm

davidm wrote:Are you really mostly focused on improving boot time though?

For overall performance I would think a SSD hard drive would help quite a bit if you don't already have one. And what kind of i3 is in there? They can range from about like an old core 2 in performance all the way up to pretty good depending on the model of the CPU. That might be a bottleneck there depending on what you have.

I wouldn't expect going to mdev to help too much...

Thank you, davidm,

My laptop is HP G62, its CPU is i3 330@2.3GHz, quite old. I use it as a target hardware environment, which means I'm able to execute my install script on different one but same CPU and Video card.

For now, boot time is the only thing I concerned.

samiswt · Post by **samiswt** » Thu Oct 22, 2015 10:40 pm

The Doctor wrote:Mdev is a serous trade off and it probably won't save too much time because it needs to do basically the same job. Static dev would probably be faster, but again trade offs.

If you really want to speed things along, look in /etc/rc.conf and set rc_parallel="YES" after you read the warnings.

Thank you Doc,

I had added that line to my rc.conf. Where could the warnings be and what do they look like? Printing on sceen? I videoed the whole booting process, there is no warning. I've done the replacement just now, I haven't got chance to check my bootchart.png, I'll update it any way, but not too much time mdev saved, as you said.

khayyam · Post by **khayyam** » Thu Oct 22, 2015 11:20 pm

The Doctor wrote:Mdev is a serous trade off and it probably won't save too much time because it needs to do basically the same job.

Doc ... well, no, mdev is considerably faster than udev, and though I've never used bootchart it certainly doesn't take '15.817 s' to do its thing. The size (and so complexity) of the execuatble is also a consideration ... mdev is a tiny 26K. There is a small "trade off" in using mdev, but that is mainly due to udev having set itself as somekind of 'standard' for devkitchensinkatude (ie, so >sys-apps/usbutils-007 doesn't build without it ... because, well, its udev, and the systemd developers made it so).

Anyhow, other than mdev, the biggest improvement you might make is to switch /bin/sh from /bin/bash to /bin/dash ... the shell used in the init process.

Code: Select all

# ls -lh /bin/{b,d}ash
-rwxr-xr-x 1 root root 670K 2015-08-25 13:48 /bin/bash
-rwxr-xr-x 1 root root  90K 2015-07-12 13:20 /bin/dash

Besides being smaller, dash is a POSIX complient shell, so you shouldn't have any issues with correctly written initscripts, or scripts expecting /bin/sh to be POSIX ... any of the former containing bashisms should be reported on bgo.

Code: Select all

# emerge app-shells/dash app-eselect/eselect-sh
# eselect sh list
# eselect sh set {n}

... where {n} is the number for 'dash' provided by 'list'.

best ... khay

samiswt · Post by **samiswt** » Fri Oct 23, 2015 4:05 pm

Hi guys, booting time is the same(38.5 s), and systemd-udevd time consuming is the same (15.817 s) as well. I've unmerged sys-fs/udev, systemd-udev should not be showing up, right?

mdev service has replaced udev at runlevel. Why is it still the same?

I'm recompiling and reinstalling kernel now, and I hope reboot will be OK.

By the way, the difference between udev and mdev is that using ctl+alt+F2, I can't switch to tty2 any more after mdev started.

And I'll try to replace bash with dash after that. Thank you!

samiswt · Post by **samiswt** » Fri Oct 23, 2015 6:10 pm

I videoed booting process again, around 34s now, I don't know why bootchart stopped working. And I also had error messages:

mdev: unknown usr/group 'root:dialout' on line 80, 81,82,83,113,114

I modified few font errors in Xorg, that might help a little bit.

samiswt · Post by **samiswt** » Fri Oct 23, 2015 6:16 pm

I'll start it all over again USE="mdev -udev".
According to this link
http://elinux.org/Boot_Time,

I believe mdev should be faster than udev.

khayyam · Post by **khayyam** » Fri Oct 23, 2015 6:42 pm

samiswt wrote:[...] booting time is the same(38.5 s), and systemd-udevd time consuming is the same (15.817 s) as well. I've unmerged sys-fs/udev, systemd-udev should not be showing up, right?

samiswt ... correct, in fact it can't because if removed its nolonger there ;)

samiswt wrote:mdev service has replaced udev at runlevel. Why is it still the same?

Not enough information to say why that's the case ...

samiswt wrote:By the way, the difference between udev and mdev is that using ctl+alt+F2, I can't switch to tty2 any more after mdev started.

Well, that works here, so it has to be something your end. BTW, mdev isn't a daemon (like systemd-udevd) so it doesn't 'start', it just executes.

samiswt wrote:And I'll try to replace bash with dash after that. Thank you!

You're welcome.

best ... khay

Post by **Leio** » Sat Oct 24, 2015 2:11 pm

If fast boot time is your concern, convert to systemd

As in, systemd instead of openrc, not systemd-udevd - though that will then come from systemd package iirc, not sys-fs/udev

Sysa · Post by **Sysa** » Sat Oct 24, 2015 3:30 pm

Leio wrote:If fast boot time is your concern, convert to systemd

I agree with Leio - systemd will allow you to tune boot process.

If you want improve working performance - mount /tmp and /var/tmp as tmpfs.

Post by **Leio** » Sat Oct 24, 2015 4:53 pm

there's nothing to tune there really, it'll be much faster thanks to the superior architecture. Though yeah, various tuning there might squeeze out another second or two, but systemd doesn't even really concentrate on fast boot times - it just happens naturally. With systemd, /tmp should be tmpfs out of the box

khayyam · Post by **khayyam** » Sat Oct 24, 2015 7:56 pm

Leio wrote:If fast boot time is your concern, convert to systemd :) As in, systemd instead of openrc, not systemd-udevd - though that will then come from systemd package iirc, not sys-fs/udev

Leio ... that particular meme has been shown to be fallacious, it may boot faster than Redhat's sysvrc but there is very little in the claim otherwise ... even systemd devs have played down this 'feature' as data provided counter-evidence (ie, boot times slowing down after some use ... go figure). Also, what you seem to be saying above is that systemd-udev's '15.817 s' is due to it being used improperly (ie, outside of systemd) ... so how does systemd make the running of systemd-udev faster? The irony is, of course, that systemd-udev is part of systemd, that's not '15.817 s' to run an rcscript that is the time taken by systemd-udev ... your suggested solution seems to be "more systemd".

Leio wrote:there's nothing to tune there really, it'll be much faster thanks to the superior architecture.

Yeah, "superior architecture" ... that is complete BS, or at minimum another unsupported claim.

best ... khay

Post by **Leio** » Sat Oct 24, 2015 8:30 pm

khayyam wrote:Leio ... that particular meme has been shown to be fallacious, it may boot faster than Redhat's sysvrc but there is very little in the claim otherwise ... even systemd devs have played down this 'feature' as data provided counter-evidence

Which is why I said it's a side-effect of the architecture/approach.

khayyam wrote:Also, what you seem to be saying above is that systemd-udev's '15.817 s' is due to it being used improperly (ie, outside of systemd) ... so how does systemd make the running of systemd-udev faster? The irony is, of course, that systemd-udev is part of systemd, that's not '15.817 s' to run an rcscript that is the time taken by systemd-udev ... your suggested solution seems to be "more systemd".

I didn't pay good attention to the initial post with the I/O times there. Seems possibly like a misconfiguration, perhaps devtmpfs isn't used and it somehow still works, but slow? Does the kernel configuration of gentoo-source (if that's what's used) have selected OpenRC or systemd configuration (whichever is used, or both), which is patched into gentoo-sources Kconfig to automatically enable for you all that's required?

Regarding that URL, I can't bother to read such unreadable grey on black, sorry.
If the slowness is truly from I/O, then need to look into that closer I suppose - udev install doesn't complain about any missing kernel options, right?

szatox · Post by **szatox** » Sat Oct 24, 2015 10:11 pm

Actually the ultimate way to reduce time from pushing_the_red_button to system_ready_for_use is.... suspending instead of shutting down.
Sure, there is some trade off, like your laptop will only be able to sleep for something like 2 days until battery runs out, but then if you need a longer break 5 seconds here or there is not going to save you, so why bother?

Now, if you really want to speed up cold boot, first thing is you don't want to have initramfs, so you would only boot your system once rather than twice before it's ready.
Second thing is give up some flexibility: replace init scripts with your own, handwritten, static boot sequence. Modifying it is going to hurt, but if you "preprocess" dependencies, so you don't have to resolve them every time it's going to remove a few seconds from the boot process.
Skipping services you don't need will help as well. And writing those scripts yourself you are likely to actually skip services you don't need.

The Doctor · Post by **The Doctor** » Sat Oct 24, 2015 10:36 pm

samiswt wrote:
The Doctor wrote:Mdev is a serous trade off and it probably won't save too much time because it needs to do basically the same job. Static dev would probably be faster, but again trade offs.

If you really want to speed things along, look in /etc/rc.conf and set rc_parallel="YES" after you read the warnings.
Thank you Doc,

I had added that line to my rc.conf. Where could the warnings be and what do they look like? Printing on sceen? I videoed the whole booting process, there is no warning. I've done the replacement just now, I haven't got chance to check my bootchart.png, I'll update it any way, but not too much time mdev saved, as you said.

The warning is in the file, along with the original setting.

My point about mdev being about the same in terms of speed is because they both use the kernel to generate nodes, but mdev doesn't set permissions; create some nodes that some programs need; and doesn't proide the library that some programs, like chromium, link to; and it won't recognize a lot of hardware correctly, like joysticks.

I see this thread is digressing into a systemd flame war, so it may well end up locked soon, but my 2 cents is that my experience with it wasn't any faster and far more unstable than OpenRC to the point where it literally damaged the OS to the point where it was unrecoverable.

khayyam · Post by **khayyam** » Sat Oct 24, 2015 11:11 pm

Leio wrote:
khayyam wrote:Leio ... that particular meme has been shown to be fallacious, it may boot faster than Redhat's sysvrc but there is very little in the claim otherwise ... even systemd devs have played down this 'feature' as data provided counter-evidence
Which is why I said it's a side-effect of the architecture/approach.

Leio ... except that you didn't say that, what you said was "f fast boot time is your concern, convert to systemd", and that was what the above was responding to. Also, its not a "side effect" if its not true, so you can't counter my contention of the claim with "its a side-effect of the architecture" ... unless you think that repeating the claim somehow makes it more true.

Leio wrote:
khayyam wrote:Also, what you seem to be saying above is that systemd-udev's '15.817 s' is due to it being used improperly (ie, outside of systemd) ... so how does systemd make the running of systemd-udev faster? The irony is, of course, that systemd-udev is part of systemd, that's not '15.817 s' to run an rcscript that is the time taken by systemd-udev ... your suggested solution seems to be "more systemd".

I didn't pay good attention to the initial post with the I/O times there. Seems possibly like a misconfiguration, perhaps devtmpfs isn't used and it somehow still works, but slow? Does the kernel configuration of gentoo-source (if that's what's used) have selected OpenRC or systemd configuration (whichever is used, or both), which is patched into gentoo-sources Kconfig to automatically enable for you all that's required?

I can't answer any of those questions, its not my machine.

Leio wrote:Regarding that URL, I can't bother to read such unreadable grey on black, sorry.

Not seeing that here ... you should be able to click the 'book' icon (firefox) and enable 'reader mode', the pages colour settings should then be disabled.

Leio wrote:If the slowness is truly from I/O, then need to look into that closer I suppose - udev install doesn't complain about any missing kernel options, right?

Again, I'm not the person having the issue ...

best ... khay

samiswt · Post by **samiswt** » Wed Oct 28, 2015 9:40 pm

After reinstalled Gentoo with USE flag -udev, and emerged all packages with mdev, those dialout errors were still there, and dpcpcd, netmount, vixcon services were unable to start at booting time.

Although I got 4s improvement, I decide to use udev again, and try to figure out alternatives.

Thank you all again! And I'll update my improvement.

eccerr0r · Post by **eccerr0r** » Wed Oct 28, 2015 10:13 pm

Ultimately it's udev that's the problem. My udev does not take 15 seconds to run, even on my Atom (the only machine I think that udev may take 15 seconds to run is my SC520 but I didn't test... Any i3 will completely blow both these SOCs away.)

The key line to look for is "udev: waiting for uevents to be processed" during boot - this is telling something is wrong. And usually it's a kernel issue...

Is there another way to improve my laptop performance?

Is there another way to improve my laptop performance?

Re: Is there another way to improve my laptop performance?

Re: Is there another way to improve my laptop performance?

Re: Is there another way to improve my laptop performance?

Re: Is there another way to improve my laptop performance?