Linked by diegocg on Sun 22nd Jul 2012 19:09 UTC
Linux 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.
Thread beginning with comment 527753
To read all comments associated with this story, please click here.
Wake Locks
by Alfman on Sun 22nd Jul 2012 20:20 UTC
Alfman
Member since:
2011-01-28

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.

Reply Score: 2

RE: Wake Locks
by Soulbender on Mon 23rd Jul 2012 03:52 in reply to "Wake Locks"
Soulbender Member since:
2005-08-18

My somewhat disconnected opinion is that the overall design seems to be a kludge


In other words, a perfect fit for the Linux kernel ;)

Reply Parent Score: 3

RE[2]: Wake Locks
by Alfman on Mon 23rd Jul 2012 04:38 in reply to "RE: Wake Locks"
Alfman Member since:
2011-01-28

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.

Reply Parent Score: 5

RE[2]: Wake Locks
by dsmogor on Mon 23rd Jul 2012 07:17 in reply to "RE: Wake Locks"
dsmogor Member since:
2005-09-01

I know it was meant funny, but this case proves otherwise. Wakelock have not yet found its place in the kernel despite huge pressure.

Reply Parent Score: 3

RE: Wake Locks
by Valhalla on Mon 23rd Jul 2012 05:14 in reply to "Wake Locks"
Valhalla Member since:
2006-01-24

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.

Reply Parent Score: 3

RE[2]: Wake Locks
by Alfman on Mon 23rd Jul 2012 05:18 in reply to "RE: Wake Locks"
Alfman Member since:
2011-01-28

I'd like somebody to explain what the differences are between androids mechanisms and what's been accepted into mainline, if anyone here knows...?

Reply Parent Score: 2

RE: Wake Locks
by dsmogor on Mon 23rd Jul 2012 07:11 in reply to "Wake Locks"
dsmogor Member since:
2005-09-01

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.

Reply Parent Score: 3