Hi. See my comments below. Jun Sun wrote: On mips interrupt is an exception and system call is a different exception. Different exceptions has different exception handlers,On Wed, Aug 13, 2003 at 04:46:04PM +0300, Sirotkin, Alexander wrote:Hello dearest all. I have a question regarding tasklets on MIPS. I suspect that there is a bug in generic MIPS kernel, but I'm not sure yet. Linux kernel has a couple of so called "checkpoints" when the system should check if there are tasklets to run and run them in the following way : if (softirq_pending(cpu)) do_softirq(); One of these places is at the end of interrupt handler (do_IRQ()), however this is not the only place. I was under impression that this code should be called after system call too. The caveat here is that on MIPS (contrary to other architectures, such as x86) system call is not an interrupt (it's a different exception) and has completely different handler. So in x86 it is sufficient to call if (softirq_pending(cpu)) do_softirq(); at the end of do_IRQ because do_IRQ handles system call too, but on MIPS it is not. Therefore I believe these lines should be added to the end of sys_syscall function on MIPS. What do you think ?softirq/tasklet/bottom_half/etc should only be raised from interrupt context. Checking at the end of do_IRQ should be good enough. at least that's what I was able to figure from entry.S file. So the system call does not go through do_IRQ and do_softirq is not called. In our kernel port we do have these lines in the timer interrupt, that is not a problem.One possible mistake in MIPS porting is that if the board uses its private time interrupt routine poeple may forget to put the above two lines at the end. Check against that. P.S. The whole issue started when we noticed that user process making many system calls has very significant impact on device drivers running in tasklet modeWhat kind of impact? On i386? Or on MIPS? Jun The impact is that if our driver works in tasklet mode then some user mode application making system calls causes some (although quite small) packet loss. It does not happen if we don't use tasklet and do everything in the ISR. I suspect that what happens is as follows : system call arrives and while it's being processed and interrupt to one of the drivers arrives. This interrupt schedules a tasklet which however is not executed after the system call finishes, only after the next timer interrupt which causes up to 10 ms latency (not all the time, only when somebody makes a system call). It only happens on MIPS. There is no easy way to check this on x86. -- Alexander Sirotkin SW Engineer Texas Instruments Broadband Communications Israel (BCIL) Tel: +972-9-9706587 ________________________________________________________________________ "Those who do not understand Unix are condemned to reinvent it, poorly." -- Henry Spencer |