Messages in this thread | | | Date | Fri, 25 Aug 2006 18:26:13 +1000 | From | Nick Piggin <> | Subject | Re: [RFC] maximum latency tracking infrastructure |
| |
Arjan van de Ven wrote: > Nick Piggin wrote:
>> Surely you would call set_acceptable_latency() *before* running such >> operation that requires the given latency? And that >> set_acceptable_latency >> would block the caller until all CPUs are set to wake within this >> latency. >> >> That would be the API semantics I would expect, anyway. > > > but that means it blocks, and thus can't be used in irq context
Is that a problem? I guess it could be, but you don't want to give a false sense of security either. Having an explicit _nosync version may make that clear?
> > (the usage model I imagine happens most is a set_acceptable_latency() > which can block during device init, > with either no or a very course limit, and a > modify_acceptable_latency(), which cannot block, from irq context or > device open)
OK. You'd know more about that than I ;)
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |