All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vernon Mauery <vernux@us.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jeff@garzik.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [-RT] multiple streams have degraded performance
Date: Tue, 19 Jun 2007 17:38:50 +0200	[thread overview]
Message-ID: <1182267530.7348.367.camel@twins> (raw)
In-Reply-To: <200706190725.30414.vernux@us.ibm.com>

On Tue, 2007-06-19 at 07:25 -0700, Vernon Mauery wrote:
> On Monday 18 June 2007 11:51:38 pm Peter Zijlstra wrote:
> > On Mon, 2007-06-18 at 22:12 -0700, Vernon Mauery wrote:
> > > In looking at the performance characteristics of my network I found that
> > > 2.6.21.5-rt15 suffers from degraded thoughput with multiple threads.  The
> > > test that I did this with is simply invoking 1, 2, 4, and 8 instances of
> > > netperf at a time and measuring the total throughput.  I have two 4-way
> > > machines connected with 10GbE cards.  I tested several kernels (some
> > > older and some newer) and found that the only thing in common was that
> > > with -RT kernels the performance went down with concurrent streams.
> > >
> > > While the test was showing the numbers for receiving as well as sending,
> > > the receiving numbers are not reliable because that machine was running a
> > > -RT kernel for these tests.
> > >
> > > I was just wondering if anyone had seen this problem before or would have
> > > any idea on where to start hunting for the solution.
> >
> > could you enable CONFIG_LOCK_STAT
> >
> > echo 0 > /proc/lock_stat
> >
> > <run your test>
> >
> > and report the output of (preferably not 80 column wrapped):
> >
> > grep : /proc/lock_stat | head
> 
> /proc/lock_stat stayed empty for the duration of the test.  I am guessing this 
> means there was no lock contention.

Most likely caused by the issue below.

> I do see this on the console:
> BUG: scheduling with irqs disabled: IRQ-8414/0x00000000/9494
> caller is wait_for_completion+0x85/0xc4
> 
> Call Trace:
>  [<ffffffff8106f3b2>] dump_trace+0xaa/0x32a
>  [<ffffffff8106f673>] show_trace+0x41/0x64
>  [<ffffffff8106f6ab>] dump_stack+0x15/0x17
>  [<ffffffff8106566f>] schedule+0x82/0x102
>  [<ffffffff81065774>] wait_for_completion+0x85/0xc4
>  [<ffffffff81092043>] set_cpus_allowed+0xa1/0xc8
>  [<ffffffff810986e2>] do_softirq_from_hardirq+0x105/0x12d
>  [<ffffffff810ca6cc>] do_irqd+0x2a8/0x32f
>  [<ffffffff8103469d>] kthread+0xf5/0x128
>  [<ffffffff81060f68>] child_rip+0xa/0x12
> 
> INFO: lockdep is turned off.
> 
> I haven't seen this until I enabled lock_stat and ran the test.

I think this is what causes the lack of output. It disables all lock
tracking features...

> > or otherwise if there are any highly contended network locks listed?
> 
> Any other ideas for debugging this?

fixing the above bug would help :-)

Ingo says that should be fixed in -rt17, so if you could give that a
spin...


  reply	other threads:[~2007-06-19 15:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-19  5:12 [-RT] multiple streams have degraded performance Vernon Mauery
2007-06-19  6:51 ` Peter Zijlstra
2007-06-19 14:25   ` Vernon Mauery
2007-06-19 15:38     ` Peter Zijlstra [this message]
2007-06-19 17:19       ` Vernon Mauery
2007-06-20  3:38 ` Vernon Mauery
2007-06-20  7:42   ` Peter Zijlstra

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=1182267530.7348.367.camel@twins \
    --to=peterz@infradead.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=vernux@us.ibm.com \
    /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.