alvise rigo <a.r...@virtualopensystems.com> writes: > On Mon, Jul 20, 2015 at 8:01 PM, Frederic Konrad > <fred.kon...@greensocs.com> 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 <alex.ben...@linaro.org> >>> 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 >>>> - [1437144337-21442-1-git-send-email-fred.kon...@greensocs.com] >>>> - 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 >>>> - [1436516626-8322-1-git-send-email-a.r...@virtualopensystems.com] >>>> - 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 >>>> - g...@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6 >>>> - [1435330053-18733-1-git-send-email-fred.kon...@greensocs.com] >>>> - 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
