[lkml]   [2010]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] Attempted summary of suspend-blockers LKML thread
    On Mon, 2010-08-02 at 21:18 -0700, Arve Hjønnevåg wrote:
    > > o A power-aware application must be able to efficiently communicate
    > > its needs to the system, so that such communication can be
    > > performed on hot code paths. Communication via open() and
    > > close() is considered too slow, but communication via ioctl()
    > > is acceptable.
    > >
    > The problem with using open and close to prevent an allow suspend is
    > not that it is too slow but that it interferes with collecting stats.

    Please elaborate on this. I expect the pm-qos stats interface will
    collect stats across user open/close because that's how it currently
    works. What's the problem?

    > The wakelock code has a sysfs interface that allow you to use a
    > open/write/close sequence to block or unblock suspend. There is no
    > limit to the amount of kernel memory that a process can consume with
    > this interface, so the suspend blocker patchset uses a /dev interface
    > with ioctls to block or unblock suspend and it destroys the kernel
    > object when the file descriptor is closed.

    This is an implementation detail only. The pm-qos objects are long
    lived, so their stats would be too. I would guess that explicit stat
    clearing might be a useful option.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-08-03 18:05    [W:0.019 / U:11.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site