[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-thinkpad
Subject:    Re: [ltp] Re: Generic battery interface
From:       Michael Olbrich <michael.olbrich () gmx ! net>
Date:       2006-08-01 11:43:03
Message-ID: 20060801114303.GA13000 () creature ! apm ! etc ! tu-bs ! de
[Download RAW message or body]

On Tue, Aug 01, 2006 at 01:45:27AM +0300, Shem Multinymous wrote:
>>And keeping the latest readout for each app isn't that heavy. After all
>>we already have to keep track of the timeouts for each app.
>
>The timeouts bookkeeping will normally be done by some infrastructure,
>and can often be (in principle) be optimized to less than on value per
>app. Also, it's just one timestamp. By contrast, what you're asking
>for requires explicit handling by every driver, and the attribute
>value may take significant amount of storage -- per app.

If you are that concerned about storage why the complex timeout model?
That can easily handled in userspace with just the blocking and
nonblocking reads.

> >Another way to handle this:
> >A lot of applications are interrested in changes. It would be perfectly
> >reasonable for a poll() to block for over 1 minute while the value
> >fluctuates with changes less than e.g. 1%. As soon as the change
> >(compared to the last readout) exceds this threshhold poll() returns
> >immediatelly. This could of course be combined with the proposed
> >timeouts.
>=20
> The app can do this itself by polling and checking the value, with a
> (not too) small value of dupeq.min_wait. In the case of a
> polling-based data source, the resulting hardware queries and timer
> interrupts are exactly the same as an in-kernel implementation which
> does the polling and comparions itself. If the data source is
> event-based then the comparison in userspace does have a drawback: the
> comparions are done just dupeq.min_wait apart even if the event rate
> happens to be higher. Can you think of a case where this matters?

The problem I see is the overhead. Visual feedback that feels
instantaneous would require dupeq.min_wait<50ms. And as far as I can
tell each read requires to switch from userspace to kernelspace and
back. When I look at the available variables I can easily imagine
applications that would read >10 variables. That's not something I would
want to do that often.

m


["signature.asc" (application/pgp-signature)]
-- 
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad

[prev in list] [next in list] [prev in thread] [next in thread]