Guest post by Linux kernel 3.5 has been released. New features include support for metadata checksums in Ext4, userspace probes for performance profiling with systemtap/perf, a simple sandboxing mechanism that can filter syscalls, a new network queue management algorithm designed to fight bufferbloat, support for checkpointing and restoring TCP connections, support for TCP Early Retransmit (RFC 5827), support for android-style opportunistic suspend, btrfs I/O failure statistics, and SCSI over Firewire and USB. Here’s the full list of changes.
Here’s a description of the controversial wake locks being merged from android.
http://lwn.net/images/pdf/suspend_blockers.pdf
My somewhat disconnected opinion is that the overall design seems to be a kludge. but the link apparently mentions google’s G1 reference hardware had inadequate power management functionality which must have influenced their design.
In other words, a perfect fit for the Linux kernel
Well, we know that there was a lot of pressure to merge google’s drivers, which are incompatible without these new wake locks, and I suspect that’s the prime reason these are being pushed into mainline.
I dislike that it’s a system wide lock, it’s a step back from the fine grained sleep states already supported by linux. It also adds a tight coupling between userspace and kernel. Now ordinary user space apps like gmail and google maps on android are responsible for system-wide power management, which seems silly to me.
Whatever the PM problems were with google’s reference hardware, they should have fixed the hardware instead of adding these crazy wake locks.
I know it was meant funny, but this case proves otherwise. Wakelock have not yet found its place in the kernel despite huge pressure.
AFAIK the original controversy was that the Linux devs thought Android’s suspend mechanism (suspend blockers) was too aggressive and therefore the Linux devs instead created ‘autosleep’ and ‘wake locks’ which offers a similar functionality but in a more flexible(?) way and are hoping that the Android devs will use these features instead of suspend blockers, they’ve also made the API mimic the suspend blocker API so as to make it as easy as possible for the Android devs to pick up.
I’d like somebody to explain what the differences are between androids mechanisms and what’s been accepted into mainline, if anyone here knows…?
Perhaps this article sheds some light on it:
https://lwn.net/Articles/479841/
Also, here is technical background on the ‘suspend blocker’ controversy: (very technical, kernel dev-style)
https://lwn.net/images/pdf/suspend_blockers.pdf
edit: nvm the second one, it’s what you linked to in the first post
Edited 2012-07-23 06:24 UTC
Not exactly. This is what got merged in: https://lwn.net/Articles/479841/.
It’s main purpose is to mimic wakelocks using existing kernel machinery in quest for running Android userland on stock Linux kernel and keep changes in drivers minimal.
Looks like some seriously nice performance boosts for the open source radeon drivers
uprobes look handy for testing application performance.
That’s what she said!
(sorry. couldn’t help it.)
“Android-style opportunistic suspend”
This looks interesting, anyone care to explain it in layman’s terms?
Tux can now go to bed more often, saving more energy for eventual world domination?
Is that ok?
Edited 2012-07-23 04:31 UTC
sb56637,
As I understand it, on a very general level they’ve added a new synchronisation lock in the kernel, which is accessed directly by userspace applications to block sleep states. Once no userspace applications hold a lock, the entire system immediately enters a sleep state. These transitions occur very frequently as one receives input.
The thing about the google G1 hardware was that it only supported a system-wide sleep state, not per-device, which is why google built that into android. But most hardware can put individual components to sleep and wake them up individually on demand, and I argue is better than a system wide sleep. Someone please correct me if I’m wrong, but I think if any android application is using one device with a wake lock, then all active yet idle devices on the system remain awake during that interval.
Thanks for the explanation!
Anyone knows why debian unstable (which I’m running) is still on 3.2?
I think because Debian is working on making a release ? They are (almost) in freeze ?
If you want a newer kernel added to SID, just add the repos from aptosid-kernel. Then you get new kernels more often. And totally compatible with SID.