From: Jeremy Fitzhardinge <jeremy@goop.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, hpa <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: x86: unify genapic code, unify subarchitectures, remove old subarchitecture code
Date: Sun, 08 Feb 2009 08:56:57 -0800 [thread overview]
Message-ID: <498F0ED9.1080906@goop.org> (raw)
In-Reply-To: <1234102566.4244.7.camel@localhost.localdomain>
James Bottomley wrote:
> The other big problem is mm/tlb.c. This directly uses genapic with 8
> vectors which is impossible for voyager: the QIC only has 8 separate IPI
> vectors for everything. The two alternatives which spring to mind are
> either to rebase mm/tlb.c on top of smp_call_function. This would add a
> small amount to the critical path, but would also allow vector scaling
> beyond the current 8 IPI vectors to a per processor number (i.e. might
> scale better beyond 8 cores).
I floated an experimental patch to do just that last year. There were
concerns because it had a pretty significantly hit on the performance of
tlb-heavy benchmarks; and since then a multicast smp_call_function ends
up kmallocing, which probably won't help matters. I got called away to
other things before really exploring all the options here, so it may
well be worth reviving that work.
> Or to keep voyager separate and move
> pieces of paravirt ops (or rather a separated piece of pv_ops) into
> smp_ops to effect the separation.
This should be easy since you can can hook all the tlb operations via
pv_mmu_ops. And to avoid duplicating a lot of similar-looking code, you
could just do a generic smp_call_function-based version.
J
next prev parent reply other threads:[~2009-02-08 16:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-08 14:16 x86: unify genapic code, unify subarchitectures, remove old subarchitecture code James Bottomley
2009-02-08 16:56 ` Jeremy Fitzhardinge [this message]
2009-02-15 17:41 ` James Bottomley
2009-02-15 22:48 ` Jeremy Fitzhardinge
2009-02-22 23:25 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2009-01-28 23:41 Ingo Molnar
2009-01-29 1:52 ` Suresh Siddha
2009-01-29 11:27 ` Ingo Molnar
2009-01-29 20:11 ` Suresh Siddha
2009-01-29 20:26 ` Ingo Molnar
2009-01-29 14:02 ` Andi Kleen
2009-01-29 20:36 ` Yinghai Lu
2009-01-29 21:04 ` H. Peter Anvin
2009-01-29 21:24 ` Tim Pepper
2009-01-29 22:14 ` Ingo Molnar
2009-01-29 22:19 ` Valdis.Kletnieks
2009-01-29 22:58 ` Tim Pepper
2009-01-29 23:27 ` Ingo Molnar
2009-01-30 9:01 ` Andi Kleen
2009-01-29 22:29 ` Ingo Molnar
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=498F0ED9.1080906@goop.org \
--to=jeremy@goop.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.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 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.