On Wed, Jul 22, 2015 at 3:56 PM, Alex Bennée <alex.ben...@linaro.org> wrote: > > 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?
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
