Live data from Hacker News

Linux Kernel Fastboot [pdf]

linuxplumbersconf.org

91–100 of 121 posts

Re: Linux Kernel Fastboot [pdf]

#91
post #26

Awesome! I'm seriously thinking about running Gentoo with Linux Clear kernel!

"running Gentoo" - Sure, waste your life compiling code for next to nothing performance benefits that will never add up to the extra time it took to compile the code..

Re: Linux Kernel Fastboot [pdf]

#92

> “mem=4096m” in cmdline to only init 2 GB What is going on that makes this 2:1?

mem= doesn't control the amount of RAM. It actually just specifies the largest physical address the kernel should try to use. The first 4GB of physical memory typically has some non-RAM things in it like the part of the physical address space that's reserved for talking to PCI devices.

If you have 2GB of RAM, 2GB of "other stuff" in the first 4GB, and specify mem=4096m, you'll end up with a kernel that sees 2GB of RAM.

Re: Linux Kernel Fastboot [pdf]

#93
post #68
post #55

Earlier quoted context omitted.

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"?

This solution didn't introduce it. The concepts being used have existed in Linux for quite some time.

Here's a patch of mine that added (some of) it from 2005: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Re: Linux Kernel Fastboot [pdf]

#94

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.

Just last weekend I was talking to one of FreeBSD's VM gurus about doing exactly this in FreeBSD too. You have to be careful about it though -- some data structures are autosized at boot, and if you're not careful you can end up with systems "running out of memory" because they have too much memory.

On Linux, most (maybe even all) of the data structures that must grow with memory size can be carved out of the memory being added. The main culprit is 'struct page' which typically needs 64b of metadata for each 4k physical page (on x86 at least). Much of the code to do this stuff is in Linux's "sparsemem" infrastructure: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Re: Linux Kernel Fastboot [pdf]

#95

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…

The XPS 13 9380 is available with Linux pre-installed, why would you want to mess with that? Or was it a fun/hobby thing?

I feel that going from 8W to 3W, while gaining a more usable system that also sits on ZFS instead of ext4, is more than enough reason.

ext4 doesn't detect corruption. How am I supposed to trust it?

Re: Linux Kernel Fastboot [pdf]

#96
post #10

Earlier quoted context omitted.

The thing with arch is it’s mostly not more tweaks that give you better battery, it’s not having all the crap that Ubuntu preloads running that makes that happen.

Folks think I'm crazy for using Arch as my main dev machine. I'm not an Ubuntu hater at all (it runs my main server in the basement at home)... but it'd be awfully hard to go back to using it as my main machine.

Really? Arch is... boring. Once you've set it up, nothing happens without your permission and you can just keep developing away. Sure you have updates imposed on you, but you can delay them a bit if you dont have time right now, and its not like upgrades are indefinitely avoidable on any other OS.

Using Arch often gives me advance warning that my apps will break on users machines due to changes in libraries. I see the changes first and can add compatibility for the new library version such that it's fixed before affecting my users.

I love it as a daily driver.

Re: Linux Kernel Fastboot [pdf]

#97
post #4

How nostalgic! Mind you, I say that in a good way! This brings me back to the heydays of Sun Microsystems where they controlled both the hardware (SPARC) and the operating system (Solaris). Sun didn't hesitate to use this to their advantage. With Clear Linux, I see Intel doing some very similar things. Yes, this was just a story about boot time, but it led me to take a look at Clear Linux and it looks like it could b…

> 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…

IIRC Clear Linux's cpufreq governor defaults to performance in contrast to the powersave governor, which most other linux distributions appear to be using. Hence the difference in idle power consumption, i guess.

Re: Linux Kernel Fastboot [pdf]

#98

Earlier quoted context omitted.

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.

I think it varies with the age of the battery and the operating temperature (probably other things too). Although if they were clever they could probably incorporate those parameters as well..

They use coulomb counting, along with an estimate of how much safely-usable energy is left in the battery.

That estimate is usually accurate, but it can drift a bit over time if you never fully recharge or discharge the battery. Also, when the battery gets old it starts having trouble delivering full current when mostly discharged, which is why you'll sometimes see shutdowns at 5-15% remaining.

Re: Linux Kernel Fastboot [pdf]

#99

Earlier quoted context omitted.

> Just remove the sleep(2700). Such high quality discussion too!

> SATA driver init takes 100 to 200 ms even without a real disk While it’s a joke, they’re not particularly far from the truth, as noted in a different comment here. They do indeed wait for some parts to respond.

2700 ms is 27x further from the truth than 100 ms.

Re: Linux Kernel Fastboot [pdf]

#100

Earlier quoted context omitted.

All Intel-compatible and emulated Intel-compatible processors do this. You'd have to run ARM to avoid it.

I thought x86 started in 64-bit mode when using UEFI?

More like the UEFI puts it into 32-bit/64-bit mode before it gets to the kernel, the hardware didn’t change.
Post reply on HN