Re: [Qemu-devel] Should we introduce a TranslationRegion with its own codegen buffer?

["Alex Bennée" <alex.bennee@linaro.org>]

Sergey Fedorov <serge.fdrv@gmail.com> writes:

> On 04/04/16 12:01, Paolo Bonzini wrote:
>> On 04/04/2016 10:54, Alex Bennée wrote:
>>> Thoughts, objections? Discuss ;-)
>> I think we're putting a lot of carts before the horse.

It is a very valid objection. I don't want to add another major code
change in while getting everything else lined up. However I thought it
merited discussion if it makes solving some of the other problems
easier.

>>
>> We have like half a dozen subprojects and none are moving because
>> there's no clear idea of what to do next and why.  The first thing to do
>> is to focus on fixing and speeding up user-mode MTTCG (Sergey's work on
>> upstreaming the patches from Fred and me) and on upstreaming Alvise's
>> work on ll/sc and TLB flushes.

FWIW I've dropped the patch that moves tb_find_fast out of tb_lock in
the upcoming base-patches-v2 series because it:
  - weirdly breaks the pxe tests
  - is pretty ugly anyway

This is obviously going to have an impact on performance which bought me
back to should we be thinking more holistically about how to approach
this problem.

In terms of focus I'm currently interested in getting Sergey's cleanups
in (which stand on their own merit of being generally cleaner for TCG)
and having a solid base-patches that is of use to everyone for testing
out the various solutions.

After the base patches are out I was going to rebuild Fred's
multi_tcg_v8 tree as *a* working implementation for ARMv7 based on a
hopefully firm foundation. I'm also looking forward to Emilio's
upcoming tree and Alvise's stop-the-world solution.

>> The second thing to do is to make tb_flush thread safe; here there are
>> three competing mechanisms (Fred's run_safe_on_cpu, Emilio's mass
>> invalidation and my idea of using RCU) that we can discuss.  Your idea
>> here is a fourth one.  It's not a bad one, not at all.  But even if it
>> has other positive side effects (e.g. easier jump patching), it's a
>> large project to embark on when there are at least three other
>> possibilities---two of them with code and the third (mine) being a
>> subset of yours.

 - async_safe_work

  I think this works but I've certainly found corner cases. Under heavy
  load the various vCPU queues do not drain evenly so you end up with
  high memory usage and the later CPUs having 1000s of deferred tasks.

 - Emilio's mass invalidation

  I need to re-read his series to remind myself of what's going on here.
  To be honest as I know he was re-spinning I was going to wait until
  the next iteration.

 - RCU based approaches

  As you say the two approaches are related, one is just an extension of
  the other but with a little more indirection. I'm fairly confident the
  architecture works as I've seen it used in other similar systems but
  making it work for QEMU is potentially messy implementation detail.

> I would agree with Paolo that this may be a bit ahead of time. But
> actually, this is an interesting idea we should definitely keep in mind
> while we're focused on more immediate work and concerning the overall
> design on MTTCG project.

My thoughts was such an approach could obviate the need to clean up the
existing patching code. But it is a big change so there is a certain
wisdom in continuing with the current less radical clean-up even if we
envision a future when we can throw that new code away ;-)

--
Alex Bennée