Boot Finding

SYSINIT(9)
He wants to replace the sorting algorythm with something faster. Maybe on his hardware, he shouldn't run a generic kernel with all kinds of modules. It is cool to have twitter to for this kind of stuff, instead of the mailing lists.
 
Colin Percival there said:

"The kernel boot (of which 7% is bubblesort) is 28 ms."

That's on a one CPU box with 128MB RAM in ~1998.

If sorting time was reduced to zero, boot would take 28 - (.07 * 28) ~= 26ms, saving ~2ms.

On modern hardware, the same task would likely run at least 4 times faster, but as Colin pointed out, now there are a lot more SYSINITs to do. So maybe this will shave all of a couple of ms off boot time.

That's the sort of dedication our lead developers have; noone is going to pay for development time expended for that sort of time savings.

I'm going to miss portsnap.
 
smithi said:
"The kernel boot (of which 7% is bubblesort) is 28 ms."
Click to expand...
28 ms? That's at least 3 cups of coffee.
How often are the sysinits actually sorted? Once at boot? If so that 28ms of boot time is lost in the noise of uptime pretty quickly. 1 hour is 3.6e6 milliseconds so that boot of 28ms is pretty much gone if the system stays up for an hour.

Optimizations are always fun and can often get ridiculous.
 
he says time to replace bubble sort with something else (faster) when it is actually time for him to replace his 1 core 128MegaByte RAM 1998 found this in a dumpster box with something else (faster).
 
mer said:
28 ms? That's at least 3 cups of coffee.
How often are the sysinits actually sorted? Once at boot?
Click to expand...

And once at shutdown, according to SYSINIT(9).

mer said:
If so that 28ms of boot time is lost in the noise of uptime pretty quickly. 1 hour is 3.6e6 milliseconds so that boot of 28ms is pretty much gone if the system stays up for an hour.
Click to expand...

My point exactly, although cperciva@'s point about spinning up a VM per web request puts 'uptime' in a different context.

(While that sounds rather extreme to me, I guess some people must be doing it.)

mer said:
Optimizations are always fun and can often get ridiculous.
Click to expand...

This one sounds like both :)
 
  • Like
Reactions: mer
smithi said:
My point exactly, although cperciva@'s point about spinning up a VM per web request puts 'uptime' in a different context.

(While that sounds rather extreme to me, I guess some people must be doing it.)
Click to expand...
I thought it was contrived too until I found the slides for his Bsdcan talk:

He's trying to get Freebsd to work inside the AWS Lambda crapola. I wish him luck, but that serverless stuff is possibly the only thing that's worse than the Terrible stack.

www.primevideotech.com

Entertainment

We create and provide access to world-class entertainment through Amazon Originals, Prime Video, Audible, Amazon Games, Twitch, Amazon Music, Prime Gaming, and more. Amazon’s digital entertainment products enable customers to access the latest apps and games, stream or download movies, TV shows,…
www.primevideotech.com www.primevideotech.com
 
Sounds like a neat new project "FirecrackerBSD". I wish it luck.

Luckily 99.999% of FreeBSD's use-case is perfectly fine with the existing init system so likely won't have a need for backporting his work.
 
Luckily, he already "backported" some of his work
Capture.PNG
 
userxbw said:
he says time to replace bubble sort with something else (faster) when it is actually time for him to replace his 1 core 128MegaByte RAM 1998 found this in a dumpster box with something else (faster).
Click to expand...
This has nothing to do with real (or old) hardware. Quite the contrary.
Colin is one (the?) of the driving forces behind the AWS FreeBSD builds/images and is now adapting/optimizing for Firecracker, which is in essence a _VERY_ trimmed down hypervisor that drops basically anything related to emulated hardware cruft that isn't necesssary to run an OS, hence you can strip away _A LOT_ of boilerplate code, drivers, hw-probing etc at boot time.
The result of that are boot times shy of 1/2 a second:
https://twitter.com/x/status/1659059445685420032
View: https://twitter.com/cperciva/status/1659059445685420032
 
sko said:
This has nothing to do with real (or old) hardware. Quite the contrary.
Colin is one (the?) of the driving forces behind the AWS FreeBSD builds/images and is now adapting/optimizing for Firecracker, which is in essence a _VERY_ trimmed down hypervisor that drops basically anything related to emulated hardware cruft that isn't necessarily to run an OS, hence you can strip away _A LOT_ of boilerplate code, drivers, hw-probing etc at boot time.
The result of that are boot times shy of 1/2 a second:
https://twitter.com/x/status/1659059445685420032
View: https://twitter.com/cperciva/status/1659059445685420032
Click to expand...
so basically curtailing it to ones own system to load what it (the user) already knows what is there and what needs to be loaded thereby skipping the whatif's searching(?)
 
kpedersen said:
From his firecracker "un-bubblesort" work? Doubt it.
Click to expand...
Sounds like some of that stuff has made it into -CURRENT? There's no boot time difference right now according to someone else on the forum. I suspect that is because the time savings are minimal, and -CURRENT has a bunch of debugging stuff enabled that slows it down.

sko said:
The result of that are boot times shy of 1/2 a second...
Click to expand...
That is still a lot of time for an API call. In the ad space, you typically have 2 seconds to serve up an ad. You'll typically lose 500ms - 1s on network overhead alone. If you lose another 500ms just to spin up a kernel to serve the request, you only have 500ms left to run your decision engine, look up ad markup, etc. It won't fly.

At work now we use 5s timeouts, which are supposed to be generous. With this nonsense, you've already lost 10% of that before you've even done any work. Yeah, not interested.

I thought about this more, and there's a potential upside to Mr. Percival's work. If he can convince Amazon to run Freebsd in Firecracker and if Amazon then starts doing so on a regular basis, they might pay some of their engineers to work on Freebsd. Those are two very big ifs, though.
 
My opinions only.
I've never been concerned with boot times, simply because I start my systems, go sip coffee while they boot and leave them running until the power goes out or a reboot is needed for an upgrade, so boot time is amortized over days or hundreds of days.
But I do recognize that there are times when shortest boot time is key. Spinning up a virtual machine of some kind, dynamically? Sure every little bit helps.
Laptops? Yeah, I can see it helping there.
So work like this is useful, perhaps even good, but don't sacrifice boot correctness over speed.
 
mer said:
I've never been concerned with boot times, simply because I start my systems, go sip coffee while they boot and leave them running until the power goes out or a reboot is needed for an upgrade, so boot time is amortized over days or hundreds of days.
Click to expand...
Firecracker is specifically aimed at 'serverless' servers (yes, marketing-buzzwords are bullshit...), so those instances are meant to be spun up only for pretty much single, short-lived tasks and destroyed a few seconds later. Don't ask me why this is considered 'better' than conventional servers...
 
You must log in or register to reply here.
Back
Top