Jivin Bou lays it down ... > Hi David, > >Jivin Bou lays it down ... > > > >>Hi all, > >> > >>sorry for posting this again (I hope whoever could comment on the > >>original post "just lost it" :) ). > >>I would appreciate anyone's thoughts on this. > >> > > > >Don't recall seeing it, but then that doesn't mean a lot ;-) > > > >>Hi all, > >> > >>On a "normal" kernel (no special tuning), kernel space tasks have more > >>priority than userspace ones? Is that correct? > >> > > > >Not as far as I know, unless a kernel task increases it's priority > >I think it is the same, of course it can do whatever it likes, you > >would have to check. > > > I think that apart from normal priorities (using nice), there are some > more priorities in the kernel (other than SCHED_NORMAL) > > > >>Here is what I am experiencing and trying to find a solution. > >> > >>I have an IXP425 based board, running madwifi for the Atheros cards, > >>acting as a wifi router. I also use userspace programs (boa http server > >>and cgi apps) to configure it. > >>When the board is on heavy load (Wireless stations connected to the > >>board and pass lots of traffic), my web apps run extremely slow. Even > >>the serial console responds that slow. > >> > > > >This is most likely due to interrupt load and "at interrupt time" > >processing. That is higher priority than processes. > > > Yes, this seems to be my problem. > > > >>Is there a solution to this? Would CONFIG_PREEMPT help at all? Or for > >>something like this you have to use a RT kernel? > >> > > > >NAPI can help, there are many drivers in the kernel that implement it > >and you may be able to apply the same techniques to whatever drivers are > >causing your latencies. > > This was GREAT info. NAPI did help a lot. Well, it is not that fast, but > response time is acceptable.
NAPI is supposed to be a useful compromise between interrupt processing and polling, so the response time should still be ok until you load the system up. Either that or I give NAPI more credit than it deserves ;-) > Many many thanks!!! > > P.S. I did not see any difference changing the weight (packets that > could be processed at once) of the poll function. Once you are saturated this will have no effect. The weight would only help when bursting, not for constant overload, Cheers, Davidm > > Cheers, > Bou > > > >>Assuming that the user space application can have a specific pid, is > >>there any "patch" that can be applied to the kernel's scheduler to give > >>it some more priority? > >> > >>I cannot tell if this slow down occurs to kernel versus user space > >>priorities, or to the bunch of interrupts per second. > >> > > > >You want to look into kernel profiling (profile and oprofile). > > > >Cheers, > >Davidm > > > > > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
