From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: 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 14:16:06 +0000 [thread overview]
Message-ID: <1234102566.4244.7.camel@localhost.localdomain> (raw)
> I ported the NUMAQ / Summit / bigsmp and ES7000 subarchitectures to the
> new setup. They build and boot on regular hardware but are otherwise
> untested. The x86/Voyager subarch is not fully ported yet (i cleaned up
> its Kconfig impact) and hence disabled it for the time being. It
> ought to be relatively straightforward to port it to the new code.
OK, so I analysed the voyager requirements.
The first simple one is that safe_smp_processor_id() and
hard_smp_processor_id() need to be abstracted, probably through smp_ops.
This one is probably trivial since 99% of the price of doing this has
already been paid in the smp ops.
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). 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. Instinct says to try the former
first.
James
next reply other threads:[~2009-02-08 14:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-08 14:16 James Bottomley [this message]
2009-02-08 16:56 ` x86: unify genapic code, unify subarchitectures, remove old subarchitecture code Jeremy Fitzhardinge
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=1234102566.4244.7.camel@localhost.localdomain \
--to=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.