[Top][All Lists]

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

Re: [Qemu-devel] Summary MTTCG related patch sets

From: alvise rigo
Subject: Re: [Qemu-devel] Summary MTTCG related patch sets
Date: Mon, 20 Jul 2015 20:29:12 +0200

On Mon, Jul 20, 2015 at 8:01 PM, Frederic Konrad
<address@hidden> wrote:
> On 20/07/2015 19:41, alvise rigo wrote:
>> Hi Alex,
>> Thank you for this summary.
>> Some comments below.
>> On Mon, Jul 20, 2015 at 6:17 PM, Alex Bennée <address@hidden>
>> wrote:
>>> Hi,
>>> Following this afternoons call I thought I'd summarise the state of the
>>> various patch series and their relative dependencies. We re-stated the
>>> aim should be to get what is up-streamable through the review process
>>> and heading for merge so the delta for a full working MTTCG can be as
>>> low as possible. There was some concern about the practicality of
>>> submitting patches where the full benefit will not be seen until MTTCG
>>> is finally merged.
>>> On the patch submission note could I encourage posting public git trees
>>> along with the patches for ease of review?
>>> BQL lock breaking patches, Paolo/Jan
>>>    - required for working virt-io in MTTCG
>>>    - supersedes some of Fred's patches
>>>    - merged upstream as of -rc0
>>> TCG async_safe_work, Fred
>>>    - http://git.greensocs.com/fkonrad/mttcg.git async_work_v3
>>>    - address@hidden
>>>    - split from earlier MTTCG patch series
>>>    - needed for cross-cpu sync mechanism for main series and slow-path
>>>    - candidate for upstreaming, but only MTTCG uses for now?
>>> Slow-path for atomic instruction translation, Alvise
>>>    - address@hidden
>>>    - Needs re-basing to use TCG async_safe_work
>>>    - Earlier part of series (pre MTTCG) could be upstreamed as is
>> I will create a branch for upstreaming (pre MTTCG) and another one
>> based on MTTCG.
>>>    - Concern about performance impact in non-MTTCG scenarios
>>>    - Single CPU thread impact may be minimal with latest version, needs
>>>    benchmarking
>>>    - Also incomplete backend support, would BACKEND_HAS_LLSC_OPS be
>>>    acceptable to maintainers while support added by more knowledgable
>>>    backend people for non-x86/arm backends?
>>> Multi-threaded TCG V6, Fred
>>>    - address@hidden:fkonrad/mttcg.git branch multi_tcg_v6
>>>    - address@hidden
>>>    - Needs re-basing on top of latest -rc (BQL breaking)
>>>    - Contains the rest of the MTTCG work (tb locking, tlb stuff etc)
>>>    - Currently target-arm only, other builds broken
>>> As far as balancing the desire to get things upstreamed versus having a
>>> stable base for testing I suggest we try an approach like this:
>>>    - select the current upstream -rc as the common base point
>>>    - create a branch from -rc with:
>>>      - stuff submitted for upstream (reviewed, not nacked)
>>>      - doesn't break any tree
>>>      - has minimal performance impact
>>> Then both Fred and Alvise could base their trees of this point and we
>>> aim to rebase onto a new branch each time the patches get merged into a
>>> new upstream RC. The question then become how to deal with any
>>> cross-dependencies between the slow-path and the main MTTCG branches?
>>  From my side I will take care of rebasing my patch series on the
>> latest MTTCG branch as often as possible. Up to now, there are not so
>> many cross-dependencies, so I don't see it as a big issue. Is this a
>> workable solution?
>> Thank you,
>> alvise
> The RFC V3 you sent is based on MTTCG if I remember right.
> That's why you introduced this rendez-vous right?


> And the point was to use async_safe_work for this as I need it actually for
> tb_flush and tb_invalidate (if we don't find any other solution for
> tb_invalidate).
> So this is the cross-dependency which we are talking of.
> But maybe and probably this is not needed with upstream as there is only one
> thread.

Exactly. I've also managed to use the plain async_run_on_cpu for the
slow-path, so I don't really think there will be problems of


> Thanks,
> Fred
>>> I suspect the initial common branch point would just be
>>> 2.4.0-rc1+safe_async.
>>> Does that sound workable?
>>> --
>>> Alex Bennée

reply via email to

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