> Are there really many such devices in use for non RT sorts of things?
> What use do they have?
Yes, all they are RT things by definition.
Seems, you miss the most important point: all the desktop systems
(and networking control nodes, btw) are real-time systems.
(Read, all the linuxes but web servers.)
They are not required to control space shuttles, but they play music,
show video etc. etc. using the cheapest hardware of available one.
Proclamations that latency better than infinite one is area
of specialized systems sound solid, but have nothing to do with reality.
Nobody requires of Linux to have 40usec guaranteed bounds (especially
on process level), but it still has to provide at least best-effort delays
and to schedule events in microsecond range.
> Isn't problem here unfocused interrupts. If you are having lock contention,
> speeding up locks is perhaps not the correct first approach.
Exactly! Do you still remember the statement, which I tried
to criticize? 8) Unfortunately, Linux really has infinite contention
in the worst cases and large one in common cases.
Did you tell about global_cli()? It is dying, there are no reasons
to preserve it but lack of programmer's time. This tendency is clear.
The problem, which really bothers me, is that there exists backward tendency.
The kernel is being polluted continuously with unnesessary irq disabling
serving only spinlock deadlock prevention. And they are caused not only
by forgivable desire to hack fastly not thinking about latency issues,
but also by absense of any reasonable mechanisms to make it more cleverly.
The word "spl" is accepted as an indecent curse, even the fact that something
"smells like spl" is considered as an argument to dump the idea.
Unfortunately, all known mechanisms are closer to spls, than to cli()
because of the first letter 's'. So that until words "it looks like spl"
will be considered indecent and inappropriate in an honest argument,
the progress is stalled. [ Dave, I am sorry, I don't distinguish humour
without explicit 8) pretty frequently. 8) ]
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/