All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.