qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC PATCH v3] target/mips: Increase number of TLB entries on the 34


From: Richard Henderson
Subject: Re: [RFC PATCH v3] target/mips: Increase number of TLB entries on the 34Kf core (16 -> 64)
Date: Fri, 16 Oct 2020 10:28:58 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 10/16/20 6:33 AM, Philippe Mathieu-Daudé wrote:
> Per "MIPS32 34K Processor Core Family Software User's Manual,
> Revision 01.13" page 8 in "Joint TLB (JTLB)" section:
> 
>   "The JTLB is a fully associative TLB cache containing 16, 32,
>    or 64-dual-entries mapping up to 128 virtual pages to their
>    corresponding physical addresses."
> 
> There is no particular reason to restrict the 34Kf core model to
> 16 TLB entries, so raise its config to 64.
> 
> This is helpful for other projects, in particular the Yocto Project:
> 
>   Yocto Project uses qemu-system-mips 34Kf cpu model, to run 32bit
>   MIPS CI loop. It was observed that in this case CI test execution
>   time was almost twice longer than 64bit MIPS variant that runs
>   under MIPS64R2-generic model. It was investigated 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
>   difference. 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.
> 
> (https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg03428.html)
> 
> Buglink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13992
> Reported-by: Victor Kamensky <kamensky@cisco.com>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> v3: KISS
> Supersedes: <20201015224746.540027-1-f4bug@amsat.org>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  target/mips/translate_init.c.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~



reply via email to

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