I fixed it, maybe. On Fri, Nov 26, 2010 at 1:52 PM, Scott Nicholas <scott.nicho...@scottn.us> wrote: > On Fri, Nov 26, 2010 at 4:39 AM, Helmut Schaa > <helmut.sc...@googlemail.com> wrote: >> >> Btw. did you check if hardware crypto is working fine? If hw crypto doesn't >> work it would fall back to software which could explain such a CPU >> utilization. >> >> Helmut >> >> > > Haven't even used any crypto yet. I do recall disabling LEDs helping. > Thinking, the other driver didn't use a separate thread. Maybe it's > the context switching and scheduling... That it'd help just to keep it > in the kernel context.... Is my last stab-in-the-dark idea anyway > without having some sort idea where the cycles are spent. > > -- > Scott >
I basically changed rt61pci_interrupt()'s last line to return rt61pci_interrupt_thread() instead of waking the thread to do the work. got a warning at run-time of course from kernel/softirq.c and net/core/skbuff.c about being in an IRQ, but CPU usage was very low, 5%. My test has been just running 'top' on serial console of device, and either downloading from my laptop a 100mb test file or just pinging the router with multiple instances of large icmp packets. I then tried having just TX in the thread. Went back up, but not soo bad. So assuming this way of checking system load is accurate, we gain a lot from removing the thread. This is probably good in a router anyway. So next, to find about functions that shouldn't run in irq context (and equivalents which can), or if there is a later place we can off-load to thread, if these helper threads can have different scheduling/priorities set, etc ...? That's all I know about, was hoping for ideas from the experts. Regards, Scott Nicholas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
