Prev: oom: introduce find_lock_task_mm() to fix !mm false positives
Next: [PATCH 08/12] oom: dump_tasks() use find_lock_task_mm() too
From: Brian Swetland on 3 Jun 2010 02:20
On Wed, Jun 2, 2010 at 11:04 PM, mark gross <640e9920(a)gmail.com> wrote:
>>
>> There are many wakeup events possible in a typical system --
>> keypresses or other input events, network traffic, telephony events,
>> media events (fill audio buffer, fill video decoder buffer, etc), and
>> I think requiring that all wakeup event processing bottleneck through
>> a single userspace process is non-optimal here.
>
> Um doesn't the android framework bottleneck the user mode lock
> processing through the powermanager and any wake up event processing
> eventually has to grab a lock through this bottleneck anyway?

For "high level" framework/application level wakelocks, yes, but lower
level components beneath the java api layer use the kernel interface
directly.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on 3 Jun 2010 13:30
On Thu, Jun 3, 2010 at 6:36 AM, mark gross <640e9920(a)gmail.com> wrote:
> On Wed, Jun 02, 2010 at 11:12:39PM -0700, Brian Swetland wrote:
>> On Wed, Jun 2, 2010 at 11:04 PM, mark gross <640e9920(a)gmail.com> wrote:
>> >>
>> >> There are many wakeup events possible in a typical system --
>> >> keypresses or other input events, network traffic, telephony events,
>> >> media events (fill audio buffer, fill video decoder buffer, etc), and
>> >> I think requiring that all wakeup event processing bottleneck through
>> >> a single userspace process is non-optimal here.
>> >
>> > Um doesn't the android framework bottleneck the user mode lock
>> > processing through the powermanager and any wake up event processing
>> > eventually has to grab a lock through this bottleneck anyway?
>>
>> For "high level" framework/application level wakelocks, yes, but lower
>> level components beneath the java api layer use the kernel interface
>> directly.
>>
> Oh.  I thought everything went through
> hardware/libhardware_legacy/power/power.c
> who else is hitting /sys/power/* in the android user mode then?

I believe everything does -- that's the thin wrapper around the kernel
interface (which will have to change slightly to meet the
suspend_blocker device/fd vs wakelock proc/sys interface, etc), which
is used by the powermanager service, the RIL, and any other low level
code. At the App/Service level, wakelocks are provided by a java
level API that is a remote interface to the powermanager.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: oom: introduce find_lock_task_mm() to fix !mm false positives
Next: [PATCH 08/12] oom: dump_tasks() use find_lock_task_mm() too