Messages in this thread | | | Subject | Re: [linux-pm] Attempted summary of suspend-blockers LKML thread | From | James Bottomley <> | Date | Tue, 03 Aug 2010 11:02:18 -0500 |
| |
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.
James
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |