All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Khem Raj" <raj.khem@gmail.com>
To: Paul Barker <pbarker@konsulko.com>, kamensky@cisco.com
Cc: openembedded-core <openembedded-core@lists.openembedded.org>,
	Richard Purdie <richard.purdie@linuxfoundation.org>
Subject: Re: [OE-core] [PATCH 1/2] qemu: add 34Kf-64tlb fictitious cpu type
Date: Wed, 7 Oct 2020 15:15:12 -0700	[thread overview]
Message-ID: <b4f13cc3-8698-9186-3d99-2f7017ab9756@gmail.com> (raw)
In-Reply-To: <CAM9ZRVst-JLA3aOa+U2Sd1Cqj8ARsAyVhCu0Yhhk5we+FKsmdQ@mail.gmail.com>



On 10/7/20 1:46 PM, Paul Barker wrote:
> On Wed, 7 Oct 2020 at 21:39, Victor Kamensky via
> lists.openembedded.org <kamensky=cisco.com@lists.openembedded.org>
> wrote:
>>
>> 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)
>>
>> [kamensky@coreos-lnx2 qemu]$ diff ~/34Kf.c ~/34Kf-64tlb.c
>> 2c2
>> <         .name = "34Kf",
>>>          .name = "34Kf-64tlb",
>> 6c6
>> <         .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << CP0C1_MMU) |
>>>          .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (63 << CP0C1_MMU) |
>>
>> Fixes https://bugzilla.yoctoproject.org/show_bug.cgi?id=13992
> 
> Forgive my ignorance as to the range of MIPS processors available but
> does any real MIPS CPU have 64 TLBs? If such a CPU model exists
> shouldn't we be using this instead of inventing a new model?
> 
> I'm a bit worried that targeting a unique, fictitious CPU model will
> lead to us wasting time debugging obscure failures that other projects
> have never seen and that would never occur on real hardware.
> 

there are many assumptions in various qemu machine emulations, this wont 
be the only one, so I am less worried about that.

  parent reply	other threads:[~2020-10-07 22:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 20:38 [PATCH 0/2] qemumips: speeding up Victor Kamensky
2020-10-07 20:38 ` [PATCH 1/2] qemu: add 34Kf-64tlb fictitious cpu type Victor Kamensky
2020-10-07 20:46   ` [OE-core] " Paul Barker
2020-10-07 21:52     ` Victor Kamensky
2020-10-07 22:11       ` Khem Raj
2020-10-07 22:04     ` Richard Purdie
2020-10-07 22:15     ` Khem Raj [this message]
2020-10-07 22:24       ` Paul Barker
2020-10-07 22:05   ` Khem Raj
2020-10-08  5:05     ` Victor Kamensky
2020-10-08  5:55       ` Khem Raj
2020-10-08  7:29   ` [OE-core] " Ross Burton
2020-10-08 11:53     ` Alexander Kanavin
2020-10-08 16:05       ` Khem Raj
2020-10-08 16:39         ` Victor Kamensky
2020-10-07 20:38 ` [PATCH 2/2] qemumips: use 34Kf-64tlb CPU emulation Victor Kamensky

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=b4f13cc3-8698-9186-3d99-2f7017ab9756@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=kamensky@cisco.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=pbarker@konsulko.com \
    --cc=richard.purdie@linuxfoundation.org \
    /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.