From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Jens Axboe <jens.axboe@oracle.com>,
linux-kernel@vger.kernel.org, npiggin@suse.de, dgc@sgi.com
Subject: Re: [PATCH 1/7] x86-64: introduce fast variant of smp_call_function_single()
Date: Mon, 17 Mar 2008 13:24:31 +1100 [thread overview]
Message-ID: <200803171324.32001.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <47DDA624.8000307@goop.org>
On Monday 17 March 2008 09:58, Jeremy Fitzhardinge wrote:
> Jens Axboe wrote:
> > On Fri, Mar 14 2008, Jeremy Fitzhardinge wrote:
> >> Jens Axboe wrote:
> >>> rom: Nick Piggin <npiggin@suse.de>
> >>
> >> Why is this necessary? How is smp_call_function_single slow?
> >
> > Because it's completely serialized by the call_lock spinlock.
>
> Hm, yes. Would it be possible to implement smp_call_function_mask in a
> generic way to avoid that? Turn the static structure into a per-cpu
> request list?
Not really. The common cases (that I can see) are either call all,
or call one. In the call all case, you would have to touch every
other CPU's request list, and that's not really any better than
what I've done in my patchest for that.
There would presumably be some cutoff where it makes more sense to
queue events to the percpu IPI lists if you are only sending to a
few CPUs. That would be trivial to implement, but... what are the
use-cases for that? The big one that I really know of is user TLB
shootdown, but that has its own vector anyway.
next prev parent reply other threads:[~2008-03-17 2:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 11:55 [PATCH 0/7] IO CPU affinity testing series Jens Axboe
2008-03-12 11:55 ` [PATCH 1/7] x86-64: introduce fast variant of smp_call_function_single() Jens Axboe
2008-03-14 18:21 ` Jeremy Fitzhardinge
2008-03-16 18:45 ` Jens Axboe
2008-03-16 22:58 ` Jeremy Fitzhardinge
2008-03-17 2:24 ` Nick Piggin [this message]
2008-03-17 7:25 ` Jens Axboe
2008-03-12 11:55 ` [PATCH 2/7] x86-64: speedup and tweak smp_call_function_single() Jens Axboe
2008-03-12 11:55 ` [PATCH 3/7] x86: add fast smp_call_function_single() Jens Axboe
2008-03-12 11:55 ` [PATCH 4/7] block: split softirq handling into blk-softirq.c Jens Axboe
2008-03-12 11:55 ` [PATCH 5/7] Add interface for queuing work on a specific CPU Jens Axboe
2008-03-12 11:55 ` [PATCH 6/7] block: make kblockd_schedule_work() take the queue as parameter Jens Axboe
2008-03-12 11:55 ` [PATCH 7/7] block: add test code for testing CPU affinity Jens Axboe
2008-03-12 16:41 ` [PATCH 0/7] IO CPU affinity testing series Alan D. Brunelle
2008-03-12 17:54 ` Jens Axboe
2008-03-12 20:37 ` Max Krasnyanskiy
2008-03-13 12:13 ` Jens Axboe
2008-03-13 14:54 ` Alan D. Brunelle
2008-03-13 15:00 ` Jens Axboe
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=200803171324.32001.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=dgc@sgi.com \
--cc=jens.axboe@oracle.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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®