> We could expose a new clock type (besides monotonic and realtime) that is > documented as non-strictly monotonic. It may return a time very slightly in > the past if readers race with clock source frequency change. The caller could > handle this situation (e.g. in user-space) by keeping its own per-cpu or > per-thread "last clock value" data structure (something we cannot do in a > vDSO) if it really cares about per-cpu/thread clock monotonicity.
That the first of two options I proposed. The problem, with respect to the immediate problem of debugging during a write deadlocking, is that it makes a more complex API which callers must understand the subtleties of. Perhaps necessary, but definitely a minus. > This could be implemented with the scheme I proposed as a prototype here: > > https://lkml.org/lkml/2013/9/14/136 I'm working my way though it. I definitely like the first patch! > Thoughts ? I was trying to tackle the "hard problem" of making *all* time reads non-blocking, with monotonicity guarantees. There has to be *some* bound on blocking times (in particular, time between reading hardware tiemrs and translating them to real time), but they can be reasonably long. I think I have an idea that could work, but given the hairiness of the timeeeping code, implementing it would be a major project. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
