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.
Order by: Score:
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 UTC 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 Score: 3

RE[2]: Wake Locks
by Alfman on Mon 23rd Jul 2012 04:38 UTC 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 Score: 5

RE[2]: Wake Locks
by dsmogor on Mon 23rd Jul 2012 07:17 UTC 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 Score: 3

RE: Wake Locks
by Valhalla on Mon 23rd Jul 2012 05:14 UTC 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 Score: 3

RE[2]: Wake Locks
by Alfman on Mon 23rd Jul 2012 05:18 UTC 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 Score: 2

RE[3]: Wake Locks
by Valhalla on Mon 23rd Jul 2012 06:22 UTC in reply to "RE[2]: Wake Locks"
Valhalla Member since:
2006-01-24

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

Reply Score: 4

RE: Wake Locks
by dsmogor on Mon 23rd Jul 2012 07:11 UTC 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 Score: 3

Comment by orestes
by orestes on Sun 22nd Jul 2012 21:27 UTC
orestes
Member since:
2005-07-06

Looks like some seriously nice performance boosts for the open source radeon drivers

Reply Score: 2

uprobes
by ideasman42 on Sun 22nd Jul 2012 23:11 UTC
ideasman42
Member since:
2007-07-20

uprobes look handy for testing application performance.

Reply Score: 3

RE: uprobes
by MechaShiva on Mon 23rd Jul 2012 01:38 UTC in reply to "uprobes"
MechaShiva Member since:
2005-07-06

That's what she said!

(sorry. couldn't help it.)

Reply Score: 0

Android-style opportunistic suspend
by sb56637 on Mon 23rd Jul 2012 04:26 UTC
sb56637
Member since:
2006-05-11

"Android-style opportunistic suspend"
This looks interesting, anyone care to explain it in layman's terms?

Reply Score: 2

Elv13 Member since:
2006-06-12

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

Reply Score: 4

Alfman Member since:
2011-01-28

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.

Reply Score: 4

sb56637 Member since:
2006-05-11

Thanks for the explanation!

Reply Score: 2

OT: why sid still on 3.2?
by r0b0 on Mon 23rd Jul 2012 06:45 UTC
r0b0
Member since:
2006-09-21

Anyone knows why debian unstable (which I'm running) is still on 3.2?

Reply Score: 1

RE: OT: why sid still on 3.2?
by Lennie on Mon 23rd Jul 2012 12:56 UTC in reply to "OT: why sid still on 3.2?"
Lennie Member since:
2007-09-22

I think because Debian is working on making a release ? They are (almost) in freeze ?

Reply Score: 3

RE: OT: why sid still on 3.2?
by judgen on Mon 23rd Jul 2012 15:06 UTC in reply to "OT: why sid still on 3.2?"
judgen Member since:
2006-07-12

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.

Reply Score: 4