Re: Issues with INET sockets through loopback (lo)

[DervishD <lkml@dervishd.net>]

    Hi Hans :)

    I've not read the code in order to not make assumptions about
proper parameters or how to make the tests. I've tested using an AMD
Athlon XP 1900+, using a self compiled 2.4.29 kernel. The measures
were made using zsh 'time'. Not quite exact but I think that's good
for comparisons anyway.

 * Hans Henrik Happe <hhh@imada.sdu.dk> dixit:
> To test this further i wrote a program (attach: random-inet.c) that shows this 
> behavior. It starts a number processes and connects them with INET sockets. 
> Then n startup messages are sent. When a process receives a message it 
> randomly selects a destination to forward it to. This way there will always 
> be n messages in transit. The issues can be observed with just 3 processes 
> and 1 message. Usage:
> 
> random-init <# processes> <# messages>

    With 3-1 I get an usage of 20% more or less. But with 16-1 the
CPU usage is nearly 0! and with 16-16 the usage is 5% more or less.

> I have tried more regular communication patterns but this gives full CPU 
> utilization as expected. For instance sending messages in a ring (attach: 
> ring-inet.c). 

    Not here. It uses 29% instead of 20% with 3-1, but drops to 6%
when using 16 processes. Far from full CPU usage. A test with 16-160
doesn't make the system slower or irresponsive, at least here...
 
> I discovered another issue when using many messages (i.e. 16 processes and 16 
> messages). The responsiveness of the system degrades massively. It takes 
> seconds before keyboard input are displayed. Of cause there are many very IO 
> bound processes, but I'm not sure if the impact should be that high.   

    Not here. I haven't noticed any slow-down or latency increase
using high number of messages. Using 16-160 only uses at most 7% of
CPU per process, and I don't feel the system irresponsive.

    If you want more accurate results, try to modify your test
programs: make them run for a couple of minutes (you decide how much
time, the longer, the better) and kill all children processes. After
that, use getrusage() (with RUSAGE_CHILDREN) or wait3(). That should
give more accurate results.

    Hope that helps. If you want to make any other test, tell me.
I'll try to help.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
-
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/