[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Summary MTTCG related patch sets
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] Summary MTTCG related patch sets |
Date: |
Wed, 22 Jul 2015 14:56:13 +0100 |
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? 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