[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] reschedule problem
Hi,
after analysing my described problem (read my old mail) I found a general problem of uClinux concerning realtime latency.
Rescheduling of my user app after the execution of the interrupt service routine in my driver fails only sometimes. This is exactly the case when a concurrently working TCP-sending thread temporarily disables kernel preemption. I've seen it happens e.g. with rcu_read_lock_bh() in ./net/core/dev.c:dev_queue_xmit(). Another disabling of preemption happens in ./net/ipv4/tcp.c:tcp_sendmsg() at goto jump label "wait_for_memory:" when the TCP stack starts to wait for the releasing of a socket buffer.
http://www.linuxdevices.com/articles/AT8211887833.html#3 seems to be related to this problem.
Hmm...first I wonder why the RCU lock stuff is not framed in something like "#ifdef CONFIG_SMP" because I understand it as it just makes sense with a multi-processor environment. Anyway, I made a hack this way and commented out local_bh_disable() in rcu_read_lock_bh() and it seems it's still working well in my single-microblaze-CPU system, with the additional effect of an improved latency. I suggest to patch here with #ifdef CONFIG_SMP, shouldn't we?
Still I have the problem with the disabling of preemption in the case of waiting_for_memory by tcp_sendmsg(), that increases the IRQ latency here up to inacceptable 10 msec! :-( I'm still analysing but it's dreadfully time-consuming with all the logging at this low kernel level.
Do you have any idea/comment etc.?
CU, F@lk
Brettschneider Falk wrote:
>
> Do you have an idea or example code how an ISR in kernel 2.6
> can force a reschedule immediately after it has finished? In
> good old kernel 2.4 times I used current->need_resched=1 to do so.
>
> My problem is, this happens in my self-written driver:
> The interrupt service function mydriver_ISR() calls
> wake_up_interruptable(&queue) but I see the appropriate
> awaking of the sleeping user space thread at mydriver_poll()
> just more than 5 milliseconds later. Probably on the next
> timer-IRQ that triggers the scheduler?
>
> I tried to call set_current_state(TASK_INTERRUPTABLE) before
> poll_wait(..,&queue,wait) in function mydriver_poll(), and to
> call set_tsk_need_resched(current) in the ISR, but without
> any improvement of that bad wakeup-latency.
>
> With my tracing to a log buffer in memory (means: no use of
> printk), I can see that no other thread is scheduled next
> than my desired user-space thread.
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/