Performance impact of SMTC varies enormously with the job mix and the
system configuration. The 34K core is based on the 24K pipeline, which
is pretty efficient, so if you're not missing in the caches or doing a
lot of targeted multiplies, there's not always a whole lot of dead
cycles to fill with multiple threads. And to sponge up cache miss
stall cycles, the memory controller has to be able to handle the
multiple streams of outstanding requests, which isn't the case in some
systems that were originally designed for the 24K. I gave a paper at
the HiPEAC conference last January which showed performance impact on
various microbenchmarks of SMTC. This looks to (finally) be freely
downloadable at http://www.springerlink.com/index/787307253g2644h4.pdf|
If you're not planning on doing anything else with the other VPE (i.e.
RTOS or some other scheduling domain), using it for virtual SMP is an
option. The kernel will be a little smaller than SMTC, and some
internal functions will be faster. You'll be limited to 2-way
parallelism, but going from 1 to 2 is always the step that gives the
biggest performance increase. The general pattern seems to be that
going from 2 to 3 gives you half again what you got from 1->2, three
to for gives you half again what you got from 2->3, etc., up to the
point where the pipeline saturates or you start thrashing the cache.
Most of the experiments I ran showed the sweet spot to be 3 or 4
threads per core. SMTC also has the slight advantage of making all
threads use a common ASID space and share the same TLB, while the VPE
SMP scheme splits the TLB between the two VPEs. This makes a
difference if you're running with large, parallel working sets, but you
won't see much of an impact on small benchmarks.
I think that the biggest potential advantage of SMTC probably comes not
from increasing throughput per se, but from using it in conjunction
with the YIELD instruction to provide zero-latency user-mode event
handling, but one has to have the right signals wired to the YQ inputs
of the core to exploit it.
Anoop P A wrote:
Thanks for your inputs.
My platforms support is not available in lmo kernel.( So I am
free to use any version of kernel :) )
Since you are the guy who wrote SMTC stuff , I think you are the
right person to answer few of my queries. How much performance
improvement you are getting in SMTC mode. Will it give us any
reasonable performance improvements.( As I could see some other negaive
comments . just curious!). Does it make sence to use SMP ( my SOC is
having 2 VPE each with couple of threads).
On Sat, Jun 13, 2009 at 2:39 AM, Kevin D.
the guy who wrote the SMTC stuff, I'd recommend picking up something
newer. Ralf has merged some of the subsequent improvements and fixes
into 2.6.18, but not the patches that I made last year to allow
tickless support, which is actually a very, very good thing to have for
SMTC. That support was initially available in 2.6.24, but subsequently
got broken by some changes to control register manipulation APIs that I
identified and fixed a few months ago. Ralf back-merged them into
several recent baselines, but I'm not sure which ones. 2.6.29-stable
seems to have all the right patches applied for SMTC, but of course I
can't tell whether there would be other issues for your platform.
Anoop P A wrote:
I have got a reference board with mips 34k core SOC.I am planning to
enable smtc/smp support . The reference kernel I am having is
linux-2.6.18 which is in uniprocessor mode.
Could any of you suggest me in which way i have to proceed?. Does it
make sense to continue using 2.6.18 or port newer kernel version (
which might be having better SMTC/SMP support)?