From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Paul Barker <pbarker@konsulko.com>, kamensky@cisco.com
Cc: openembedded-core <openembedded-core@lists.openembedded.org>,
Khem Raj <raj.khem@gmail.com>
Subject: Re: [OE-core] [PATCH 1/2] qemu: add 34Kf-64tlb fictitious cpu type
Date: Wed, 07 Oct 2020 23:04:32 +0100 [thread overview]
Message-ID: <769d0e90ad1512b1a3fa62bf40687a7210660968.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAM9ZRVst-JLA3aOa+U2Sd1Cqj8ARsAyVhCu0Yhhk5we+FKsmdQ@mail.gmail.com>
On Wed, 2020-10-07 at 21:46 +0100, Paul Barker wrote:
> On Wed, 7 Oct 2020 at 21:39, Victor Kamensky via
> lists.openembedded.org <kamensky=cisco.com@lists.openembedded.org>
> wrote:
> > [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.
In this case we're playing with a single configuration value which is
dynamically handled by the kernel and used at this range in other areas
like mips64 so whilst I don't like doing this, a 40% speedup for
qemumips is very very tempting.
I think the maintenance burden and risk is low, the win is significant.
I have to thank Victor for some great analysis and what I think is
quite an ingenious solution!
I'll put it in for some testing and see where things go...
Cheers,
Richard
next prev parent reply other threads:[~2020-10-07 22:04 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 [this message]
2020-10-07 22:15 ` Khem Raj
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=769d0e90ad1512b1a3fa62bf40687a7210660968.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=kamensky@cisco.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=pbarker@konsulko.com \
--cc=raj.khem@gmail.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 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.