public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Steve Sakoman <steve@sakoman.com>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][dunfell 7/8] qemu: add 34Kf-64tlb fictitious cpu type
Date: Sun, 18 Oct 2020 15:27:03 +0100	[thread overview]
Message-ID: <ce3f803cce21cd9ca80c4701c3ede32a8c2ee10c.camel@linuxfoundation.org> (raw)
In-Reply-To: <464f9f50bce368fb5109a5d7cc06cc25b0bfbe6a.1602771116.git.steve@sakoman.com>

On Thu, 2020-10-15 at 04:15 -1000, Steve Sakoman wrote:
> From: Victor Kamensky <kamensky@cisco.com>
> 
> In Yocto Project PR 13992 it was reported that qemumips
> in autobuilder runs almost twice slower then qemumips64 and
> some times hit time out.
> 
> Upon investigations of qemu-system with perf, gdb, and
> SystemTap and comparing qemumips and qemumips64 machines
> behavior it was noticed that qemu soft mmu code behaves
> quite different and in case if qemumips tlbwr instruction
> called 16 times more oftern. It happens that in qemumips64
> case qemu runs with cpu type that contains 64 TLB, but in case
> of qemumips qemu runs with cpu type that contains only
> 16 TLBs.
> 
> The idea of proposed qemu patch is to introduce fictitious
> 34Kf-64tlb cpu type that defined exactly as 34Kf but has
> 64 TLBs, instead of original 16 TLBs.
> 
> Testing of core-image-full-cmdline:do_testimage with
> 34Kf-64tlb shows 40% or so test execution real time
> improvement.
> 
> Note for future porters of the patch: easiest way to update
> the patch and be in sync with 34Kf definition is to copy
> 34Kf machine definition and apply the following changes to
> it (just change 15 to 63 of CP0C1_MMU bits value)

There is discussion upstream about just changing the tlb to 64 for this
machine. I'd suggest we hold off this for dunfell until its resolved
there.

Cheers,

Richard


  reply	other threads:[~2020-10-18 14:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 14:15 [OE-core][dunfell 0/8] Patch review Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 1/8] Revert "package: get_package_mapping: avoid dependency mapping if renamed package provides original name" Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 2/8] timezone: update to 2020b Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 3/8] scripts/oe-build-perf-report: Allow operation with no buildstats Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 4/8] oe-build-perf-report: Ensure correct data is shown for multiple branch options Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 5/8] bitbake-bblayers/create: Make the example recipe print its message Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 6/8] uninative: Fix typo in error message Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 7/8] qemu: add 34Kf-64tlb fictitious cpu type Steve Sakoman
2020-10-18 14:27   ` Richard Purdie [this message]
2020-10-19 15:48     ` Steve Sakoman
2020-10-15 14:15 ` [OE-core][dunfell 8/8] qemumips: use 34Kf-64tlb CPU emulation Steve Sakoman
     [not found] ` <163E30094343B958.12811@lists.openembedded.org>
2020-10-16 14:34   ` [OE-core][dunfell 1/8] Revert "package: get_package_mapping: avoid dependency mapping if renamed package provides original name" Steve Sakoman
2020-10-17  7:55     ` Richard Purdie
2020-10-22 10:59       ` Martin Jansa

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=ce3f803cce21cd9ca80c4701c3ede32a8c2ee10c.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=steve@sakoman.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox