On 18.02.19 20:16, Michael S. Tsirkin wrote: > On Mon, Feb 18, 2019 at 07:29:44PM +0100, David Hildenbrand wrote: >>> >>>>> >>>>> But really what business has something that is supposedly >>>>> an optimization blocking a VCPU? We are just freeing up >>>>> lots of memory why is it a good idea to slow that >>>>> process down? >>>> >>>> I first want to know that it is a problem before we declare it a >>>> problem. I provided an example (s390x) where it does not seem to be a >>>> problem. One hypercall ~every 512 frees. As simple as it can get. >>>> >>>> No trying to deny that it could be a problem on x86, but then I assume >>>> it is only a problem in specific setups. >>> >>> But which setups? How are we going to identify them? >> >> I guess is simple (I should be carefuly with this word ;) ): As long as >> you don't isolate + pin your CPUs in the hypervisor, you can expect any >> kind of sudden hickups. We're in a virtualized world. Real time is one >> example. >> >> Using kernel threads like Nitesh does right now? It can be scheduled >> anytime by the hypervisor on the exact same cpu. Unless you isolate + >> pin in the hypervor. So the same problem applies. > > Right but we know how to handle this. Many deployments already use tools > to detect host threads kicking VCPUs out. > Getting VCPU blocked by a kfree call would be something new. > Yes, and for s390x we already have some kfree's taking longer than others. We have to identify when it is not okay. > >>> So I'm fine with a simple implementation but the interface needs to >>> allow the hypervisor to process hints in parallel while guest is >>> running. We can then fix any issues on hypervisor without breaking >>> guests. >> >> Yes, I am fine with defining an interface that theoretically let's us >> change the implementation in the guest later. >> I consider this even a >> prerequisite. IMHO the interface shouldn't be different, it will be >> exactly the same. >> >> It is just "who" calls the batch freeing and waits for it. And as I >> outlined here, doing it without additional threads at least avoids us >> for now having to think about dynamic data structures and that we can >> sometimes not report "because the thread is still busy reporting or >> wasn't scheduled yet". > > Sorry I wasn't clear. I think we need ability to change the > implementation in the *host* later. IOW don't rely on > host being synchronous. > > I actually misread it :) . In any way, there has to be a mechanism to synchronize. If we are going via a bare hypercall (like s390x, like what Alexander proposes), it is going to be a synchronous interface either way. Just a bare hypercall, there will not really be any blocking on the guest side. Via virtio, I guess it is waiting for a response to a requests, right? -- Thanks, David / dhildenb
