[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [rtl] RT Ethernet
On Fri, Sep 10, 1999 at 10:45:55AM +0200, Tomasz Motylewski wrote:
> On Thu, 9 Sep 1999, Michael M. Morrison wrote:
>
> > It appears (from several messages) that we are not supposed to be doing any
> > dev_alloc_skb()'s if they are eventually calling kmalloc(). The funny thing
> > is that the machine has been running constantly for the past 3 days with no
> > errors at all, and has been dev_alloc'ing skb's 800 times per second. I
> > will look into changing this in our code, however.
>
> This is because these dev_alloc_skb() et al. functions are designed to be
> called from the interrupt, thus are almost real time.
Um... no. kmalloc() and slab allocators grab spinlocks. Linux interrupts are protected
from interrupting a spinlock, RTLinux interrupts are not. On a UP kernel,
in an RTLinux interrupt, if you try to grab a spinlock that is already
taken, it always succeeds immediately without warning, and you will probably
end up with corruption in whatever the spinlock was protecting. On an SMP
kernel, it will work most of the time, but will deadlock if the Linux code
that already owned the lock is running on the same process as the RTLinux
interrupt.
Obviously, the probability of getting spinlock contention is very small
on a quiet machine. On a machine that is using full bandwidth on both
an RT ethernet interface and normal interface, you will get corruption
and/or deadlocks _very_ fast. I've seen it happen reproducably in less
than a second.
Also, kmalloc() defaults to no debugging, so even if you get corruption,
it's not logged.
I think there is no
> problem with them blocking, because they get memory from a small pool which
> is always kept free (about 200-1000 KB).
Non-blocking isn't the only requirement for real-time. You also need to
eliminate contention with non-real-time code, as well as making sure that
the code you call does not decide to do "housekeeping chores", similar
to what the slab allocator will do. This will randomly increase latency.
It may not matter for some applications, but it makes maximum latency
auditing difficult.
> In my opinion the network code in standard Linux is already very close
> to real-time.
It's not even close. What does mark_bh() mean in an RTLinux interrupt?
Linux networking has one big bottleneck, that also happens to be the
biggest problem for real-time use: In several places, it's single-threaded.
It only has one input queue. Should we share the input queue with
non-real-time networking?
> Recompiling the whole linux/net and linux/drivers/net subdirectories without
> -D__RT__ flag and testing it would make very interesting experiment :-)
Don't bother. You've just turned your real-time system into a system that
only pretends to be real-time.
dave...
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/