[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080327120244.GL12346@kernel.dk>
Date: Thu, 27 Mar 2008 13:02:44 +0100
From: Jens Axboe <jens.axboe@...cle.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org, npiggin@...e.de, paulus@...ba.org,
tglx@...utronix.de, mingo@...hat.com, tony.luck@...el.com,
Alan.Brunelle@...com
Subject: Re: [PATCH 0/5] Generic smp_call_function(), improvements, and smp_call_function_single()
On Thu, Mar 27 2008, Ingo Molnar wrote:
>
> * Jens Axboe <jens.axboe@...cle.com> wrote:
>
> > I very much wanted the kthread approach to work, since it's easier to
> > work with. It's not for lack of will or trying... I'll be happy to
> > supply you otherwise identical patches for this, the only difference
> > being kthread of IPI completions if you want to play with this.
>
> i'd love to be able to run/pull something simple that enables me to
> replicate the measurements you did on a generic PC [without having to
> hit any real IO hardware which would put any context switching effects
> down into the noise category].
You can pull io-cpu-affinity or io-cpu-affinity-kthread from
git://git.kernel.dk/linux-2.6-block.git - or just see the two attached
patches, apply either one to current -git to test it.
> Obviously since the kthread approach embedds IPI sending it can never be
> as fast as a pure IPI approach - but it should still be reasonably fast.
> 3 usecs versus 2 usecs in a microbenchmark sounds about right to me, but
> it would be better to make it a better-sounding 2.5 usecs versus 2 usecs
> or so :-)
If you have ideas to speedup the kthread approach, fire away :-)
--
Jens Axboe
Download attachment "io-affinity-ipi.patch.bz2" of type "application/x-bzip" (15107 bytes)
Download attachment "io-affinity-kthread.patch.bz2" of type "application/x-bzip" (6966 bytes)
Powered by blists - more mailing lists