Hi Daniel, Thanks for the comments! And my reply in line: On Wed, Sep 02, 2015 at 10:19:03AM +0200, Daniel Vetter wrote: > > > > > > Also you obviously have to complete the copying from shadow->guest ctx > > > before you send the irq to the guest to signal ctx completion. Which means > > > there's really no overall problem here from a design pov, the only thing > > > > Right. We cannot control when guest driver sees seqno change, but we > > can control when guest sees context interrupts. The guest CSB update > > and interrupt injection will be after we finish writing guest > > contexts. > > > > So right now we have two options of context shadowing: one is to track > > the whole life-cycle of guest context, and another is to do the shadow > > work in context schedule-in/schedule-out time. Zhi draws a nice > > picture of them. > > > > Currently we do not have concrete performance comparison of the two > > approaches. We will have a try and see. And about this patchset, I > > will remove the "context notification" part and send out an updated > > version. Thanks! > > > > > you have to do is fix up bugs in the host code (probably you should just > > > write through the ggtt). > > > > Sorry could you elaborate a little more about this? Guest context may > > not always be in aperture right? > > Yeah the high-level problem is that global gtt is contended (we already > have trouble with that on xengt and there's the ongoing but unfished > partial mmap support for that). And permanently pinning execlist contexts > will cause lots of troubles. > > Windows can do this because it segments the global gtt into different > parts (at least last time I looked at their memory manager), which means > execlist will never sit in the middle of the range used for mmaps. But > linux has a unified memory manager, which means execlist can sit anywhere, > and therefore badly fragment the global gtt. If we pin them then that will > cause trouble after long system uptime. And afaiui xengt is mostly aimed > at servers, where the uptime assumption should be "runs forever". In server side, we do not expect host to run much graphics workloads (all should be in virtual machines with shorter uptime). But yeah, gm fragmentation is still an issue. Thanks for the explanation! > > Compounding factor is that despite that I raised this in the original > review execlist is still not yet using the active list in upstream and > instead does short-time pinning. It's better than pinning forever but > still breaks the eviction logic. > > What Chris Wilson and I talked about forever is adding an object-specific > global_gtt_unbind hook. The idea is that this would be called when > unbinding/evicting a special object (e.g. hw context), and you could use > that to do the host signalling. That would be the perfect combination of > both approaches: Thanks for the suggestion! That sounds great! Right now in XenGT part we still plan to try the shadow context work in context schedule-in/out time. With this way, we do not need to pin context as well as the host notification. We will collect some performance data to see how it works. I sent out v2 patch set which has removed the pin/unpin of execlist contexts. The patchset addressed review comments from you, Chris and Joonas(Sorry I forgot to add CC to related people). Is that patch set OK to be merged? Thanks! Regards, -Zhiyuan > > - Fast: host signalling (and therefore shadow context recreation) would > only be done when the execlist context has actually moved around. That > almost never happens, and hence per-execbuf overhead would be as low as > with your pinning solution. > > - Flexible: The i915 memory manager is still in full control since we > don't pin any objects unecessarily. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
