Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Kernel Fastboot [pdf]

linuxplumbersconf.org

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Linux Kernel Fastboot [pdf]

#61

Post by wtallis »

ComputerGuru wrote: post #36
jtchang wrote: post #16

> SATA driver init takes 100 to 200 ms even without a real disk That's pretty interesting. Wonder what it is doing?

SATA controller firmware has a hard-coded “drive predelay” that waits before enumerating attached devices, a relic from the days long before SSDs. Even when an option to set a custom amount is available in the BIOS, it is in addition to and not instead of, as there’s no bus master to tell it all attached disks have init and the controller may speak to them. It wouldn’t necessarily have to be done synchronously up fro…

The delay in question is in initializing the Linux driver, not in the system firmware scanning for bootable devices before running Linux. The Linux driver may be taking a while for similar reasons as the firmware delay you describe.

The hard drive predelay is also not as obsolete as you may think; I've encountered high-capacity SATA SSDs that take a surprisingly long time to come up after being hotplugged, to the point that Linux doesn't always succeed in bringing up the link on the first try.

Re: Linux Kernel Fastboot [pdf]

#62

Post by webreac »

loki49152 wrote: post #31
bt848 wrote: post #23

Earlier quoted context omitted.

Booting a Sun in the 90s took so long that we had the janitor go and power up the CAD lab half an hour before anyone got to the office. Whatever you are nostalgic for wasn’t a Sun.

Our Sun lab ran on SunOS 4.1.1. Its NFS implementation was so unstable we'd get perhaps an hour and a half of use at a stretch before the file server would reboot... on an 8 machine network.

When I was student, we had around 80 machines without local disk. It was working fine. They added local disks the year after with a sensible gain of performance. I loved this machine.

Re: Linux Kernel Fastboot [pdf]

#63

Post by fmntf »

bmurphy1976 wrote: post #44

I'd really like to get my raspberry pi booting in a couple seconds. I have a few ideas for things I'd like to try but the boot time is too long. Don't need X11 but I would like to use raspbian.

If you do not need the graphical stack, there is room for optimization both in kernel and user space. On a similar board (4 ARM cores) with Ubuntu I managed to start user space applications in <2 seconds (from power on) and the complete boot (including Xorg/MATE) in <10 seconds. If you are interested, on Medium I have some write-up (same username, last post).

Re: Linux Kernel Fastboot [pdf]

#64

Post by jlgaddis »

aidenn0 wrote: post #29
Filligree wrote: post #5

Earlier quoted context omitted.

> Anyone have some experiences with this distro (for better or worse) that they'd like to share? Not much of one, but for a while I was playing with multiple distros trying to find the best possible power management for my laptop. (XPS 13 9380.) Clear did better than the Ubuntu installation that came with it -- but a dead octopus would have done better than that . It was sitting at 6W for non-CPU-intensive work, and…

Firefox will suspend running pages when it is unmapped, so I put it on its own virtual desktop and only switch to that desktop when I need a webpage.

And, if you're like me and have dozens of tabs open for weeks on end, the OneTab extension is pretty awesome too.

Re: Linux Kernel Fastboot [pdf]

#65

Post by yaantc »

nobleach wrote: post #7
Filligree wrote: post #5

Earlier quoted context omitted.

> Anyone have some experiences with this distro (for better or worse) that they'd like to share? Not much of one, but for a while I was playing with multiple distros trying to find the best possible power management for my laptop. (XPS 13 9380.) Clear did better than the Ubuntu installation that came with it -- but a dead octopus would have done better than that . It was sitting at 6W for non-CPU-intensive work, and…

I'd love to hear more about the tweaks you've done to Arch. I've gone little beyond a few power management things myself (On a Thinkpad X1C Gen 6). I get decent battery life, but I know it could be better. And giving up Arch would be a tough sell to myself.

I have the same laptop as you. Just install the "tlp" package (The Laptop Project). I'm using Debian but the Arch package should have the same name. You can tweak the settings (/etc/default/tlp on Debian) but out of the box that should get you arround ~4W depending on what is running on your laptop. With light usage that gives more than 10 hours of battery life, even if you don't charge the battery to the max to increase its life (see START/STOP_CHARGE_THRESH_BAT0 for Thinkpads in the tlp configuration).

If you have a SSD you can be aggressive on the disk suspend timeout, as there's no spin up/down wear issue as with mechanical disks.

With this the battery life is good enough that I never felt the need to optimize further.

[1] https://linrunner.de/en/tlp/tlp.html

Re: Linux Kernel Fastboot [pdf]

#66

Post by satanspastaroll »

anon1m0us wrote: post #24
NelsonMinar wrote: post #2

I love the bit on slide 16 where initializing 8GB of RAM takes 100MS, so they boot with only 2GB and then hotplug in more memory later.

We've been progressively loading webpages for years. It's like the 7th layer of the stack is working its way down.

Lazy loading is not unique for the web or in anyway a new idea. The web is in fact one of the last places it has appeared in.

Re: Linux Kernel Fastboot [pdf]

#67

Post by nullify88 »

nobleach wrote: post #7
Filligree wrote: post #5

Earlier quoted context omitted.

> Anyone have some experiences with this distro (for better or worse) that they'd like to share? Not much of one, but for a while I was playing with multiple distros trying to find the best possible power management for my laptop. (XPS 13 9380.) Clear did better than the Ubuntu installation that came with it -- but a dead octopus would have done better than that . It was sitting at 6W for non-CPU-intensive work, and…

I'd love to hear more about the tweaks you've done to Arch. I've gone little beyond a few power management things myself (On a Thinkpad X1C Gen 6). I get decent battery life, but I know it could be better. And giving up Arch would be a tough sell to myself.

I run Fedora on a Thinkpad X1C Gen 3. tlp[1] has been, by far, the best tool in optimising my power usage. powertop for some monitoring, as these days it recommends some less than ideal tunables, especially with regards to SATA power management ("med_power_with_dipm" vs "min_power" [2][3]).

Some modules also have blacklists that prevent certain power saving modes from being enabled. This is true for the snd-hda-intel module to prevent a well known popping sound. Since disabling the blacklist, I haven't encountered the issue however YMMV. Similarly to enable ASPM on the PCIE bus, I've had to force it via a kernel parameter.

With regards to the GPU, I noticed my Intel GPU can scale its frequency between 300mhz and 950mhz but the default minimum was set to 350mhz. Other such tweaks such as enabling frame buffer compression [4], can save you a few more watts.

While the Linux defaults does its best to be suitable across different hardware configurations, you'll have to meddle with many parameters to get it customised to your configuration, and that could bring some instability with it so exercise some caution.

Oh, and also be mindful of the apps you run. The Great Suspender for Chrome can save you some watts, cpu and memory by suspending tabs that are not in use. And switching to a light desktop such as Sway or i3 can also do wonders.

As I type this, my battery is reporting a draw of 3.1 watts, 30% battery remaining with 4:40 of operating time at the current workload.

[1] - https://wiki.archlinux.org/index.php/TLP

[2] - https://hansdegoede.livejournal.com/18412.html

[3] - https://wiki.archlinux.org/index.php/Power_management#SATA_A...

[4] - https://wiki.archlinux.org/index.php/Intel_graphics#Framebuf...

Re: Linux Kernel Fastboot [pdf]

#68

Post by madez »

Twirrim wrote: post #55
NelsonMinar wrote: post #2

I love the bit on slide 16 where initializing 8GB of RAM takes 100MS, so they boot with only 2GB and then hotplug in more memory later.

There are some drawbacks to that. Memory flagged as hotplug can't be used by the kernel itself (because otherwise unplugging the RAM would risk crashing the system). That includes things like network buffers and a number of things which use the total RAM size as a guideline. There was a bug in a proposed kernel patch a while back, that we were testing. It ended up designating a good chunk of the machine's RAM as hotp…

Isn't the solution introducing another type of memory abstraction in the kernel next to "available since boot" and "hot pluggable", namely "later added but won't be removed"?

Re: Linux Kernel Fastboot [pdf]

#69

Post by konstmonst »

jimmaswell wrote: post #19
lonelappde wrote: post #15

Earlier quoted context omitted.

That's a good way to estimate but not appropriate for comparing to powertop, due to overhead. Also "50%" of energy is an estimate based on voltage, not actually energy usage. That's why Apple has stopped showing percentages in their OSes. You should use the same methodology for both.

I'd assume the voltage->percentage function was worked out and the percentage displayed was thus accurate. It would be weird if that wasn't the case.

It us not. I programmed Accu controller. The best way is to track the enery coming in and out. Using only voltage is imprecise bevause the voltage/charge graph look a bit logarihmic, so the more charge you have, the more presision you need to have while measuring charge.This graph as well as total possible energy capacity and ability to Charge depend on Temperature. Also you normally have multiple cells that age differently.

Re: Linux Kernel Fastboot [pdf]

#70

Post by diroussel »

satanspastaroll wrote: post #66
anon1m0us wrote: post #24

Earlier quoted context omitted.

We've been progressively loading webpages for years. It's like the 7th layer of the stack is working its way down.

Lazy loading is not unique for the web or in anyway a new idea. The web is in fact one of the last places it has appeared in.

Indeed. In apps lazy loading is something you add when you need it. But for kernels, it’s the first problem you tackle: how to pick yourself up with your bootstraps. Booting is tricky now, and it always has been. Right back to the early machines that were booted by manually entering machine code via switches.

Interestingly AWS virtual machines still boot in 16-bit mode, then bootstrap up through 32 and then 64 bit modes, last I heard.

Post reply on HN