All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <andi@firstfloor.org>,
	Peter Zijlstra <peterz@infradead.org>,
	torvalds@osdl.org, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [2/2] Don't complain about disabled irqs when the system has paniced
Date: Wed, 3 Sep 2008 12:26:01 +0200	[thread overview]
Message-ID: <20080903102600.GP20055@kernel.dk> (raw)
In-Reply-To: <200809032017.42237.nickpiggin@yahoo.com.au>

On Wed, Sep 03 2008, Nick Piggin wrote:
> > > For call_function_single, queueing could really help with high interrupt
> > > loads like the block completion migration that Jens has been looking at.
> >
> > But does it or not?
> 
> Well yes. It was basically impossible to implement without this IIRC,
> due to performance problems. And that code itself also showed some
> improvements in cases. I think it may need more tuning and testing.

The old code was useless for this, far too slow. With the new code I've
been able to demonstrate VERY good benefits from migrating interrupts,
both in synthetic cache locality benchmarks but also from something as
general as the compilebench test app (where reductions in system time
are as huge as 20-40%!). I hope to be able to share these results soon.
I have a rough profile from last week on XFS.

http://brick.kernel.dk/lock_rq0

vs

http://brick.kernel.dk/lock_rq1

rq0 is normal interrupt handling, rq1 is with rq_affinity set to 1 for
that block device queue. With that set, request completions are migrated
to the CPU that submitted them.

That is the whole reason why I got into generalizing the IPI function
call handling.

-- 
Jens Axboe


  reply	other threads:[~2008-09-03 10:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-02 13:49 [PATCH] [0/2] Fix panic regression in 2.6.27 Andi Kleen
2008-09-02 13:49 ` [PATCH] [1/2] Add a SYSTEM_PANIC state Andi Kleen
2008-09-03 19:04   ` Andrew Morton
2008-09-03 19:16     ` Andi Kleen
2008-09-03 19:32       ` Andrew Morton
2008-09-03 19:44         ` Andi Kleen
2008-09-02 13:49 ` [PATCH] [2/2] Don't complain about disabled irqs when the system has paniced Andi Kleen
2008-09-02 14:28   ` Peter Zijlstra
2008-09-02 14:40     ` Andi Kleen
2008-09-02 14:45       ` Peter Zijlstra
2008-09-02 15:00         ` Andi Kleen
2008-09-03  6:02           ` Nick Piggin
2008-09-03  6:59             ` Andi Kleen
2008-09-03  9:37               ` Nick Piggin
2008-09-03  9:48                 ` Andi Kleen
2008-09-03 10:17                   ` Nick Piggin
2008-09-03 10:26                     ` Jens Axboe [this message]
2008-09-12 19:50   ` Pavel Machek

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=20080903102600.GP20055@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=peterz@infradead.org \
    --cc=torvalds@osdl.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.