Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "The Linux 3.15 kernel now in its early life will be able to suspend and resume much faster than previous versions of the Linux kernel. A few days ago we saw ACPI and Power Management updates that enable asynchronous threads for more suspend and resume callbacks. Carrying out more async operations leads to reduced time for the system suspend and then resuming. According to one developer, it was about an 80% time savings within one of the phases. On Friday, work was merged that ensured the kernel is no longer blocked by waiting for ATA devices to resume. Multiple ATA devices can be woken up simultaneously, and any ATA commands for the device(s) will be queued until they have powered up. According to an 01.org blog post on the ATA/SCSI resume optimization patches, when tested on three Intel Linux systems the resume time was between 7x and 12x faster (not including the latest ACPI/PM S&R optimizations)."

There's a reason why RAID controllers tend to wake up drives sequentially. The power load of waking up 20 hard drives at the same time can be tremendous compared to the load when they're all spinning and purring. So you don't do that.

So I hope that power draw is taken into account, and that there will be options to limit the number of devices woken up simultaneously.

If your UPS dies, a suspended machine is screwed just the same. There's rather little point in suspending a server: even ones that are off outside business hours are better off hibernating rather than suspending.

even ones that are off outside business hours are better off hibernating rather than suspending.

"Better off" HOW? Hibernation takes much, much longer on both ends, and the difference in power consumption between hibernate and suspend is nominal. When your cluster suddenly needs more power, you don't want to wait 10 minutes for POST, kernel booting, and copying quite a few GBytes from disk into RAM,

When your cluster suddenly needs more power, you don't want to wait 10 minutes for POST, kernel booting, and copying quite a few GBytes from disk into RAM, when you can instead get up and running in a few seconds.

You may know ahead of time when your systems are most at work, say 0800-1800, so WOL at 0730, for exmple.

Not necessarily. Windows desktop machines can write out RAM to disk so that if power is lost during suspend, the machine can come back up to where it left off. It is basically a cross between suspend and hibernate. If power is maintained the machine comes up out of suspend almost instantly, if not it comes out of hibernate.

Consider that Linux runs on everything. It's not unlikely that there are plenty of clusters out there that suspends whole computers when the power is not needed. If they are also filled with HDDs, then that use case arises.

No, but but that one time a year when it does, it will be important to power the drives in sequence, not all at once.

The parallel start can still help though. There is a period of time between the inrush where the platters are at about the right speed but not yet stable. That's the point where powering the next drive on would be OK.

Something tells me that machines with a heavily RAID-ed disk subsystem are not exactly your usual candidates for frequent power cycles.

In my case - which you may dismiss as anecdotal - they are. We live in the countryside, and so power outages are common, especially during the summer. So we have a pair of UPSs backing up the servers (about 1½ hours capacity with all disks spinning). The servers are three Synology boxes, all with RAID - two are the two-bay type, one is a four-bay type, and all drive bays are occupied with 3TB and 4TB drives, totalling 14TB in RAID (raw 28TB). Another pair of smaller UPSs keep the networking gear going,

But what system with dozens of hard drives in it would be entering and exiting S3 constantly anyway?

You might do power saving on hypervisor hosts, but on a SAN? I can't think of a scenario where it makes a lot of sense... but perhaps I'm just lacking the proper imagination:P

On topic: I think this is awesome. I want to be able to suspend my machine and wake it up whenever I feel like it, with VMs shuffling around waiting for me to pick up a different tablet, or sit at a different desk. x86 has a lot of

But what system with dozens of hard drives in it would be entering and exiting S3 constantly anyway?

It doesn't have to be constantly. Once is enough.

And you don't even need dozens of hard drives. Workstations with RAID 10 aren't all that uncommon. Being able to not have all drives spin up all at the same time would be beneficial, especially as the power supply gets older - even after as little as a year of constant use, the ability to handle high loads can easily be half or less of what it was when new.

While a motherboard BIOS will take care of spinning up drives sequentially at boot, it won't help for

After all, I've gotten pretty used to putting a device "to sleep" and "waking it up" instantly.

This is a UI issue. Mobile devices can simply turn off the display before they've actually entered sleep mode. How would you know? Your PC could do the same thing, but there would be fans running and lights flashing, so you'd be aware that it was trying to trick you.

And the RAID controllers will continue to do just that. All this change does is allow the kernel to continue resuming without having to wait for the device to report that it's ready. Any commands sent to the device in the meantime are queued.

Yes, and it matters a whole lot more to us power users with lots of data! Even with large 3TB+ hard drives, it can take lots of drives to fit all of our data. My motherboard has 6 SATA ports and I have an SATA controller with 4 extra ports. Waking up 10 drives at the same time is an extra 20A of load or so on the 12V rail. That requires a fairly solid, high quality/high current PSU (admittedly I do have that).

I doubt the MD driver or the ZFS pool even can take care of it. Unlike a hardware RAID, they do not (and can not without losing functionality) hide the underlying component devices (which may only be a partition and not a whole drive).

On my SandyBridge-era Thinkpad Edge, with:- one 7200rpm Hitachi drive from ~ 2011 and- one Intel SSD 525 from ~ 2013,Debian Testing/Sid with kernel 3.13-1-amd64 wakes up from RAM sleep in 1s or so, thus extremely covenient so I never shutdown/hibernate.. how much more improvement can you get?..

Some perspective is needed here:
We're talking about almost-a-decade-old hardware running a current linux version. Yet it's still fast enough to resume within 5 seconds, boot in 45 seconds, start libreoffice in 4 seconds, IOW: still quite usable
My $200 says you can't run Mavericks on a (similar vintage!) PowerBook G4 with the same usability...

I have an x230 that I put a Corsair SSD in. It's running Ubuntu 13.10, so I guess it's running a 3.11.something kernel. On resume I can see the kernel block for 10+s (by the timestamps in dmesg) waiting for my SSD to get its act together. Screen is on, lockscreen is displayed... but I can't enter a password because the entire system is waiting on the disk.

Think embedded. A device in complete sleep state can be powered for eons on a battery. Waking, doing whatever it needs to do and then going back to sleep waiting for the next interrupt is critical to battery life. In the micro-controller world the difference in battery life of 2 seconds of wake-up time can mean the difference between swapping out your batteries in a day or in a year. I have not very fond memories of counting how many cycles various assembly instructions will take to ensure the CPU on small

A more useful metric, IMO, is how reliable the suspend/wakeup cycles are. For example, a particular Fedora 16 box I ran would suspend/resume with 100% reliability. That is, it would suspend every time you asked it to, and wake up every time you asked it to. Another Fedora 20 machine has 100% sleep and 0% wake. ie it goes to sleep and NEVER WAKES UP without a hard power cycle. Another machine had 100% sleep and about 75% wake, which is again utterly useless.

And there lies the problem. Windows is very tolerant of badly-configured ACPI implimentations - it'll happily work even if half the configuration fields are wrong, as it simply ignores them and uses hard-coded suboptimal values. There's little incentive for OEMs to bother supporting any OS other than Windows, so typically once the firmware works for Windows it is considered good enough. All is well, until we stick linux on it - and linux then follows the ACPI specification correctly, and fails horribly.

The sloppiness in the PC ACPI world can also bite Windows too. You can find nice Asrock mini PCs based on laptop hardware. If you look at a Tom's hardware review of the Asrock VisionX 420, with a mobile core and mobile AMD GPU, you'll see that it consumes 28W at idle. This is crazy high for what's in effect a mobile laptop in small form factor box. One of the big reason is that the system ACPI says that PCIe ASPM (the low-power mode of PCIe) is not supported. Configuring laptop-mode on Linux and forcing ASP

It simply doesn't resume. HIbernation always works. You can see it on videos:

http://www.pg.gda.pl/~jkozicki... [pg.gda.pl]
The *.mov files are records from hibernation/suspend attempt. They have polish names, ignore that. You can see that it reboots again right at the end of resume, then boots into log-in screen

Well, if you'd bothered to read TFA, you would have known that there was a merge last night that specifically benefits the resume process. While it may or may not help you specifically, it is definitely NOT old news. BTW, your "new and better site" makes no mention of this at the time of this writing.

There are quite a few things that slow booting systems. Systemd is _supposed_ to take a lot of the slow, sequential starup out of the actual system daemons: it will be a while before it's really working well for critical, production systems, but that can take minutes off of startup time in a large environment. Note, also, that much of its "startup advantage" is illusory. Daemons are told to start up, and systemd keeps them starting up, but they're not necessarily available for quite some time after startup. This especially applies to databases and bulky Java applications.

The kernel startup is another big factor. Scanning for, assessing, and activating drivers for all the potentially available hardware is a slow and painful process because the upstream specifications are poorly documented, and even violated by many vendors. Many of them are legacy drivers and could in theory be discarded in most production kernels, but doing so can be quite tricky and hard to test for enough strange configuration cases.

The third big software factor is the BIOS. "coreboot", formerly "LinuxBIOS", is blazingly fast compared to most proprietary BIOS's. It has made some inroads but is still not available for any commercial systems I can find. So no matter what is done in the other two factors, the BIOS is still a limiting factor of suspend and restore delays.

The third big software factor is the BIOS. "coreboot", formerly "LinuxBIOS", is blazingly fast compared to most proprietary BIOS's. It has made some inroads but is still not available for any commercial systems I can find. So no matter what is done in the other two factors, the BIOS is still a limiting factor of suspend and restore delays.

POST has to be performed by the BIOS when restoring from hibernation, but NOT suspend. So no, the BIOS is NOT a significant "limiting factor of suspend and [resume]" operations.

Modern UEFI BIOS implementations, even when booted to CSM mode, tend to spend an extremely short amount of time doing work pre-boot. The BIOS slowness was mostly due to heaps of unnecessary memory tests and diagnostics anyway. Once those stop happening, there's not much time spent getting ready for booting at all. Windows 7 on my Windows 8-shipped laptop with an SSD comes up to a ready-to-go desktop in less than 10 seconds from power on. The BIOS speed obstacle is largely solved on new machines.

I'm glad it's improved for your laptop: I agree that it's gotten better especially for laptops and SSD drives. I also agree that UEFI is helping. Unfortunately, I've tended to deal with servers, where it is _not_ a solved problem.

Modern UEFI BIOS implementations, even when booted to CSM mode, tend to spend an extremely short amount of time doing work pre-boot.

I admin several UEFI booting servers, and they can take several minutes probing and verifying hadware and firmware before the boot commences.The switch from BIOS to UEFI has not helped one bit - rather the opposite, as the drive containing the UEFI boot binaries has to be enumerated and verified before the binaries can be loaded.

Keep in mind that the kernel needs to not only work with PCs, but servers and embedded devices (where there's neither BIOS nor UEFI). Making things work well for 80% and to hell wi

Tell me when they can make my laptop last for more than an hour without mains and I'll be happy. I need to upgrade but battery life under Linux is so woeful I can't justify spending the ridiculous prices they are asking these days. To get a similar laptop to the 3 yr old one I have (at least in terms of size, weight, memory and disk) I would have to spend the same amount today as back then. Where is Moore's law again? Even though I can't afford one, I was looking at the Dell XPS 13 but for a couple of hundred more (for similar specs) I could get a macbook air and have *double* the battery life with osx. I would even consider it if I could run Linux on it and get similar battery life to osx... But alas, I read it sucks just as much as on all other machines.

You know, an idle kernel doesn't use much of your battery life. Bulky programs that crunch and munch on the CPU do. Saying, "Linux this" and "OS X that" doesn't make sense unless you know that it boils down to the kernel and kernel drivers. Have you run powertop to examine exactly which processes and drivers are responsible for draining your battery? Have you followed the recommendations given by powertop?

Finally, have you considered the possibility that your battery might be crap, and that a higher capaci

I tried powertop a few years ago but never had much success, though that was probably v1. I'll give it another try, thanks for the heads up.

A friend dropped the laptop about a year ago (it was an "accident", though he was drunk...). It didn't seem to make a difference for the first 8-9 mths but it weakened the lid/screen joint and with 12 mths of opening/closing has started to degrade seriously. I could spend many hours to try and patch it up but I've never had much success with anything more complicated th

I recently got a Thinkpad X240 with the large batterypack (total of 96wh), + an extra batterypack of 23wh, have had it for 2 months now. It's running ubuntu 13.10 and i'm getting about 10-12hours of active usage from it daily. I also always bring the extra batterypack in case of emergency.

Hey, thanks heaps for that. The X240 looks pretty much exactly like what I am after, and Lenovo (here in France) seems to let you mix and match upgrades which is seriously cool. What upgrades did you make with your system to get those numbers? Did you up the RAM to 8GB? Do you have an SSD (on top of the cache disk)? What proc do you have? How much extra weight does the larger battery pack add? 12.5" will be noticeably smaller than my current 14" - how do you find the screen?Thanks!

Hi!
I basically maxed everything relating to hardware, didn't select the I7 cpu though, I5-4300u has the virtualization support i sometimes need, and i prefer to have more battery instead of peak performance. This laptop could possibly use less energy under some workloads if selecting the I3 cpu, i'm not certain though.

People don't have any real faith in Linux distros to properly suspend or resume in the first place, much less the speed at which they perform. That needs to be more in like with Windows or OS X before they can even begin to improve its speed.

You must be young. I still remember back when Gates was talking about making ACPI a black box (unfortunately it still is, I can see) so that no other vendors but Microsoft could use the power interface. Some companies (like Intel) are pretty good about these types of specifications. I still have an Intel desktop/workstation board on my main computer at home and it has no problems sleeping and waking up.

I have had, unfortunately, problems with some other manufacturers doing the same thing - like Asus. (By th

.... um, it's 2014, the linux kernel is a critical part of the planet's internet infrastructure, is used in TVs, routers and phones all over the world, and you're *seriously* telling me that its internals aren't fully parallelised? i thought the linux kernel was supposed to be a leading example of modern operating system design and engineering.

That's an interesting point. As a Linux user for many years, I never cared about boot or resume time. That's only mattered recently, as handheld devices have become quite useful. My servers and desktop stay powered on for years at a time, so I never cared how many seconds a reboot takes. Obviously a tablet is different. With a tablet, I do care, I want it to start up and shutdown quickly.

You're assuming a lot there. How would you know if osx or windows NT kernels are 'fully parallelized'? Have you seen the source?

someone else answered about OSX. NT, based on the MACH kernel, has been fully re-entrant and multi-threaded for a looong time. also, given that the service control manager (which is a parallelised start/stop daemon service) is fully parallelised i'd be incredibly surprised if the same attention to detail wasn't also carried through on device-driver initialisation as well. although.... the only evidence against that is the "Debug Startup" mode, which initialises drivers in sequence (and shows you the sequ

I'm in beta and I click classic which is on top it gets me to classic, hit the comments link and brings me back to beta and this is in a fucking loop. Stupid assholes, a website should be about the content itself not the bullshit eye candy which is taking space anyway. FUCKING RETARDS!!!