ksoftird doesn't work like it should (?)
- From: "Aritz Bastida" <aritzbastida@xxxxxxxxx>
- Date: Tue, 28 Mar 2006 12:26:57 +0200
Hello everybody.
First of all, thank you all of you that helped me when i was doing my
thesis project: olsson, greg k-h, ... I could learn a lot (although
i'm still a newbie, of course) in these 8 months, and wrote in this
mailing list when i was too lost...
Well, you won't remember me, but I had to design a network analysis
system in kernel space. Letting apart that is or is not useful (I
didnt choose that, I just had to do it), I made some testing that
could be interesting, or that's what i think.
That's why I would like to share it with you. Here I attach a link to
a picture, which show the problems they happen when the network load
goes high.
http://www.flickr.com/photos/57861108@N00/119255818/
This picture shows the throughput of a network analysis system in user
space (not mine), with different injection speeds.
x axis: traffic speed (packets per second)
y axis: analyzer throughput (packets per second)
You can see that, when the network traffic is low, the network
analyzer can process all the packets (straight line), but when it gets
too high, it starts losing packets. If it gets even higher, the
ksoftirqd kernel thread starts eating 99.9% CPU time, even if it is
supposed that its priority is the lowest possible, so the throughput
goes lower. ksoftirqd is supposed that would not starve user programs,
but the system almost goes to livelock. The system stabilizes around
1.2 Gpps.
So what we can conclude here is that ksoftirqd doesnt work as it
should, or maybe do_softirq() is called from more places apart from
the ksoftird kernel thread. In any case, the user process almost
starves.
If you'd like, i have more pictures similar to this, and the
"solution" i found, which tries to make the throughput to be constant
independently of the traffic speed.
Regards
Aritz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Prev by Date: Re: kernel BUG at fs/direct-io.c:916!
- Next by Date: Re: OOM kills if swappiness set to 0, swap storms otherwise
- Previous by thread: 2.6: Load average calculation?
- Next by thread: Fix pacct bug in multithreading case.
- Index(es):
Relevant Pages
- Re: Ethernet issue: works one way but not another
... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected
directly to internet through ... FBSD, I have been working with BSDI at the isp
I work for for the last ... As for my network topology, I have an internal network that
goes ... (freebsd-questions) - Re: Update: UDP 770 Potential Worm
... > the network immediately after the 'attack', ... were no packets indicating
some form of replication. ... I noticed that the UDP ... > of the UDP datagrams
is the IP address of the proxy? ... (Incidents) - Re: IDSIPS that can handle one Gig
... especially with 64-byte UDP packets. ... There are plenty of network
IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily
by testing it with real-world attacks from ... (Focus-IDS) - Re: iptables and dhcp
... > the same physical network segment as the firewall and the remote DHCP ...
You used INPUT and not FORWARD chain ... # This target allows packets to be marked
in the mangle table ... (comp.os.linux.networking) - Re: Update: UDP 770 Potential Worm
... > were no packets indicating some form of replication. ... > my capture
was limited due to the switched ... to see if the problem occurs on the test network, ...
The proxy had already been isolated from the ... (Incidents)