Pasi Sjoholm writes:
> Pid: 2, comm: ksoftirqd/0
> EIP: 0060:[<e0871224>] CPU: 0
> EIP is at rtl8139_poll+0xb4/0x100 [8139too]
> EFLAGS: 00000247 Not tainted (2.6.7-mm7)
> EAX: ffffe000 EBX: 00000040 ECX: df4824f8 EDX: c0441978
> ESI: df482400 EDI: e0868000 EBP: dff85f80 DS: 007b ES: 007b
> CR0: 8005003b CR2: b7c5a000 CR3: 1fafd000 CR4: 000006d0
> [<c0119580>] ksoftirqd+0x0/0xc0
> [<c02c5f3a>] net_rx_action+0x6a/0x110
> [<c01191a9>] __do_softirq+0xa9/0xb0
> [<c01191d7>] do_softirq+0x27/0x30
> [<c01195e8>] ksoftirqd+0x68/0xc0
> [<c01277e5>] kthread+0xa5/0xb0
> [<c0127740>] kthread+0x0/0xb0
> [<c0102111>] kernel_thread_helper+0x5/0x14
> --
>
> I'm not a kernel expert but it would seem that ksoftirqd is in some sort a
> loop because I didn't get any "printk("%s wakes ksoftirqd\n",
> current->comm);"-lines.
Hello!
This looks very much like the problem we see when doing route DoS testing
with Alexey.
In summary: High softirq loads can totally kill userland. The reason is that
do_softirq() is run from many places hard interrupts, local_bh_enable etc
and bypasses the ksoftirqd protection. It just been discussed at OLS with
Andrea and Dipankar and others. Current RCU suffers from this problem as well.
I've experimented some code to defer softirq's to ksoftirqd after a time as
well as deferring all softirq's to ksoftirqd. Andrea had some ideas as well
as Ingo.
Cheers.
--ro
|