Hi Micael,
I ask again: please do a Reply to All. This discussion is CCed on
several mailing lists, not just link-thinkpad.
On 8/1/06, Michael Olbrich <[email protected]> wrote:
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.
Please explain how this can be done in a way that (a) works
transparently with both event-driven and query-based drivers, (b)
handles multiple clients efficiently, (c) minimizes hardware queries
in the case of query-based drivers, and (d) doesn't cause unnecessary
timer interrupts on tickless kernels.
> 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.
This is relevant only to query-based drivers, not event-based. How
expensive is a context switch compared to a typical hwmon hardware
query?
Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
