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. 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 > >
