[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 0/1] mips: add 34Kf-64tlb fictitious cpu type like 34Kf but with

From: Victor Kamensky
Subject: [PATCH 0/1] mips: add 34Kf-64tlb fictitious cpu type like 34Kf but with 64 TLBs
Date: Mon, 12 Oct 2020 13:36:12 -0700

Hi Qenu MIPS guys,

Could you please review and, if possible, accept a simple patch, following
this cover letter, that introduces new fictitious 34Kf-64tlb MIPS cpu
model. It is exact copy of 34Kf MIPS cpu model only the number of TLBs is
bumped up from 16 to 64.

This change and use of 34Kf-64tlb model brings up performance of
running non-trivial Linux user-land load under qemu-system-mips by
40% or more.

Yocto Project uses qemu-system-mips 34Kf cpu model, as recommended
by [1], to run 32bit MIPS CI loop. It was observed that in this
case CI test execution time was almost twice longer [2] than 64bit MIPS
variant that runs under MIPS64R2-generic model. It was
investigated [3] and concluded that the difference in number of TLBs
16 in 34Kf case vs 64 in MIPS64R2-generic is responsible for most of
CI real time execution diffrence. Because with 16 TLBs linux user-land
trashes TLB more and it needs to execute more instructions in TLB
refill handler calls, as result it runs much longer.

Proposed fix that Yocto Project adopted locally already as private
patch is to create and use 34Kf-64tlb cpu model, that is the same as
34Kf but with bigger number of TLBs.

Yocto Project would appreciate very much if this change can
be accepted by qemu project. It would reduce burden of porting
forward private patch. Other users of qemu-system-mips could
benefit from the change and new model as well.



[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13992

[3] https://lists.openembedded.org/g/openembedded-core/message/143099

Victor Kamensky (1):
  mips: add 34Kf-64tlb fictitious cpu type like 34Kf but with 64 TLBs

 target/mips/translate_init.c.inc | 55 ++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]