From: DervishD <lkml@dervishd.net>
To: Hans Henrik Happe <hhh@imada.sdu.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Issues with INET sockets through loopback (lo)
Date: Mon, 23 May 2005 14:09:00 +0200 [thread overview]
Message-ID: <20050523120900.GA339@DervishD> (raw)
In-Reply-To: <200505231317.44716.hhh@imada.sdu.dk>
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...
next prev parent reply other threads:[~2005-05-23 12:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-23 11:17 Issues with INET sockets through loopback (lo) Hans Henrik Happe
2005-05-23 12:09 ` DervishD [this message]
2005-05-24 12:12 ` Hans Henrik Happe
2005-05-24 12:23 ` Avi Kivity
2005-05-31 16:18 ` Hans Henrik Happe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050523120900.GA339@DervishD \
--to=lkml@dervishd.net \
--cc=hhh@imada.sdu.dk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.