Messages in this thread | | | Date | Fri, 17 May 2002 14:55:29 +0200 | From | Andrea Arcangeli <> | Subject | Re: Process priority in 2.4.18 (RedHat 7.3) |
| |
On Fri, May 17, 2002 at 02:01:30PM +0100, Alan Cox wrote: > > On Fri, May 17, 2002 at 01:49:21PM +0100, Alan Cox wrote: > > > I think its mostly #2. We invoke ksoftirq far far too easily. > > > > ksoftirqd + SCHED_FIFO is like no ksoftirqd at all, provided the ne card > > is irq driven (it is) everything works like it was working in 2.4.0. > > For a 10Mbit ne2k it ought to be if its done with sched fifo. For serious > devices its not. The ksoftirqd bounce blows everything out of cache and is > easily measured
if you're under a flood of irq ksoftirqd or not won't make differences to the softirq handling, and yes in such case ksoftirq cannot help because you are under a flood of do_softirq anyways run from irq context and it is only a minor scheduler overhead in such case, but it gets right all and polishes all the other "recursion" cases like NAPI.
But that has nothing to do with this case, here the userspace runs with SCHED_FIFO in a loop so ksoftirqd cannot make any difference compared to 2.4.0 if the device is irq driven, so I don't see your point in mentioning minor performance regressions while under a flood of irqs due the minor scheduler overhead, here the minor scheduler overhead cannot apply because ksoftirqd has not a chance to run at all.
Also I'd be nice if he could try with mainline (or 2.4.19pre8aa3) too just in case, we didn't had any confirm that such proggy uses SCHED_FIFO or SCHED_RR, even if I of course agree about the supposions made by Andrew without having access to additional informations.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |