there is a critical difference between RT that can be accomplished
statistically or through buffering and RT that cannot. Not that showing
video is unimportant, but that the methods you use to smooth video
presentation are different than what you use to control a machine tool
with little jitter.
And while some networking needs hard RT, for most networking is it not
correct that a few dropped packets now and then are worth higher
throughput in general?
Of course, the correct solution is tht the RT patch be added to the
standard kernel, but then you should be aware that it will be
important to make sure that it is alsways clear what is using the RT
interrupt control and what is not, so that RT is not used to
compensate for lack of design in components that are not RT.
>
> 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.
If you meant millisecond, I agree. But I am not hopeful that one
can achieve this without a major redesign.
On the other hand, Gigabit ethernet means a packet every 1.5us.
>
> > 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.
I proposed to Linus about 2 years ago that we should make some fast atomic
data structure tools available to driver writers so that they can ignore
most synchronization issues. He correctly suggest I send in some working
code, but ...
what bothers me is three problems of incorrect analysis
(A) Hard Realtime is not needed nearly as often as people suppose and
it is often invoked as a shorthand for "my application can be optimized
by pessimizing everything else."
(B) The tradeoff between optimizing common case and optimizing
worst case is easy to ignore.
(C) One of the reasons why RTLinux is useful is that it decouples
the hardRT component from the main OS. Many people do not understand
why this is important and see it as merely an inconvenient design
flaw. But to imagine that something as complex and fundamentally
geared towards common case performance as Linux can be put in a blender
with an RTOS to produce a palatable result is delusion.
> 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) ]
There are excellent reasons to avoid spls. Among these reasons, not
all architectures support them, and hardware ideas of priority are often
completely wrong. However, it is quite easy to use the RTLinux soft
interrupt handler to provide arbitrary grouoings of interrupt sources so that
you could have a
disable_network_interrupts
which might disable atomically a serial device carrying hdlc, 2 pic
network cards and a firewire/ngio type device.
And without RT, something like
void __not_reentrant__ my_irq_handler( .... )
would be useful especially if "return" then would generate
delayed calls.
-
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/