[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    [uClinux-dev] PREEMPT_RT
From:       "Falk Brettschneider" <falk.brettschneider () gmx ! de>
Date:       2008-06-25 10:57:54
Message-ID: 20080625105754.37530 () gmx ! net
[Download RAW message or body]

Hi,
has anybody ported the PREEMPT_RT patch to uClinux (best would be kernel 2.6.20, microblaze) or can say \
if it would help for the following problem?:

My system is microblaze, kernel 2.6.20, kernel preemption patch (CONFIG_PREEMPT) enabled.

I wrote a Linux kernel driver that just notifies IRQs in its ISR and wakes a wait_queue where my SCHED_RR \
user-application (in user space) is waiting on it while sleeping in poll(). Normally, the user app is \
scheduled next and poll() awakes quite fast (0.5msec). But if concurrently another process is sending \
much data via TCP/IP I see the behaviour that the TCP stack (which is runing in software by the Linux \
kernel itself) locks kernel preemption for up to 10 msecs. For example, when tcp_sendmsg cannot skb_alloc \
new packets and jumps to label wait_for_memory, where it calls release_socket() for waiting till packets \
are available again. This blocking call also blocks preemption for any reasons. In such time window my \
driver can collect IRQs in its ISR but the scheduler is blocked and my user app doesn't wake up. Although \
it has the highest SCHED_RR priority in the whole system. I've seen other scenarios with similar \
behaviour.

I'm wondering if PREEMPT_RT would help for e.g. such scenario?
Any other idea is highly appreciated. :-)

I know Linux is not a realtime OS but I'd like to tune it that TCP/IP doesn't block the scheduler for \
such IRQ translating from Linux driver to SCHED_RR application.

Cheers, Falk

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


[prev in list] [next in list] [prev in thread] [next in thread]