mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans Henrik Happe <hhh@imada.sdu.dk>
To: DervishD <lkml@dervishd.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Issues with INET sockets through loopback (lo)
Date: Tue, 24 May 2005 14:12:17 +0200	[thread overview]
Message-ID: <200505241412.17887.hhh@imada.sdu.dk> (raw)
In-Reply-To: <20050523120900.GA339@DervishD>

On Monday 23 May 2005 14:09, DervishD wrote:
> 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.

That even worse than what I have experienced.
  
> > 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...

Again, even worse.
 
> 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.

That's strange. Maybe I should try an AMD system myself. Btw the number of 
processes is an upper bound of the number of messages. This is just a 
simplification in the code.

> 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.

I could do that, but my point is that kernel goes into the idle state even 
though there always should be a runable process. Your tests supports this.
I don't believe that more accuracy would help because it is quite clear that 
CPU is in the idle state.
 
> Hope that helps. If you want to make any other test, tell me.
> I'll try to help.

Thanx. Your tests actually confirms the first issue, which also is the one 
that I have been most concerned about. 

I hope that someone with knowledge of how this part of the kernel work can 
confirm that this is a problem with the kernel or explain why it is supposed 
to behave in this manor.

Hans Henrik Happe

  reply	other threads:[~2005-05-24 12:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-23 11:17 Hans Henrik Happe
2005-05-23 12:09 ` DervishD
2005-05-24 12:12   ` Hans Henrik Happe [this message]
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=200505241412.17887.hhh@imada.sdu.dk \
    --to=hhh@imada.sdu.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@dervishd.net \
    /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

all inboxes | Powered by JetHome®