On 10/20/25 04:14, Akihiko Odaki wrote: ... >>> So, if you know some workload that may suffer from the delay, it may be >>> a good idea to try them with the patches from Alex first, and then think >>> of a clean solution if it improves performance. >> >> Thanks a lot for the clarification. I'm seeing occasional 10ms stalls >> with this patch applied, still it's a huge improvement. Looking forward >> to v2. > > Just for (further) clarification, but 10ms stalls are present even > without this patch (correct me if I'm wrong). I think the stalls need to > be resolved with another patch instead of having v2 of this unless it is > a regression.
Stalls present without this patch and they are much worse than with your patch. Without your patch - unmaping stalls for 50-100ms, with your patch - unmapping stalls for 2-20ms. There are no stalls at all with patches from Alex, unmapping finishes instantly and performance is ideal. >> In addition to a guest waiting for the virgl commands completion, QEMU >> display updates on host are also blocked while unmapping cmd is >> suspended. This is a noticeable problem for interactive GFX applications >> running on guest. > > I guess you meant that the scanout commands following unmapping commands > are blocked. While I can imagine that can cause frames skipped and > damage user experience, it is nice if you know reproduction cases or > affected workloads and share them with me. Correct, scanout commands are blocked. Running pretty much any VK application with venus reproduces the problem. A simple reproduction case is to run vkmark with venus, it would noticeably stall between switching benchmark modes and when app quits. With native contexts the problem is much more visible. Running any Desktop Environment (KDE Plasma in my case) on guest with amd/intel nctx would be freezing badly by moving application window around desktop. -- Best regards, Dmitry
