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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox