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 <michael.olbrich@xxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
