[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: |
Wed, 22 Jul 2015 16:10:35 +0200 |
On Wed, Jul 22, 2015 at 3:56 PM, Alex Bennée <address@hidden> wrote:
>
> alvise rigo <address@hidden> writes:
>
>> 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?
>>
>> 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
>>> TCG
>>> 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
>> cross-dependencies.
>
> Does that mean (performance permitting) any of the patch set can go
> upstream before the main MTTCG patch set?
Yes. A version of the patch series based on upstream QEMU (no
multithreading at all) does not require any of the patches introduced
by MTTCG.
On the contrary, a version made to work with MTTCG will have few
cross-dependencies.
Regards,
alvise
> Or is it intimately tied to
> Fred's set for now?
>
>>
>> Regards,
>> alvise
>>
>>>
>>> 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
>>>
>>>
>
> --
> Alex Bennée
Re: [Qemu-devel] Summary MTTCG related patch sets, Frederic Konrad, 2015/07/20