|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] Linux kernel polling for QEMU |
Date: | Wed, 7 Dec 2016 12:38:34 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
On 12/02/2016 12:12 PM, Stefan Hajnoczi wrote:
On Thu, Dec 01, 2016 at 09:35:27AM -0500, Paolo Bonzini wrote:Maybe we could do the same for sockets? When data is available on a socket (or when it becomes writable), write to a user memory location. I, too, have an interest in polling; in my situation most of the polling happens in userspace.You are trying to improve on the latency of non-blocking ppoll(2)/epoll_wait(2) call?Yes, but the concern is for throughput, not latency. My main loop looks like execute some tasks poll from many sources Since epoll_wait(..., 0) has non-trivial costs, I have to limit the polling rate, and even so it shows up in the profile. If the cost were lower, I could poll at a higher frequency, resulting in lower worst-case latencies for high-priority tasks.IMHO, the ideal model wouldn't enter the kernel at all unless you _want_ to go to sleep.Something like mmapping an epoll file descriptor to get a ring of epoll_events. It has to play nice with blocking epoll_wait(2) and ppoll(2) of an eventpoll file descriptor so that the userspace process can go to sleep without a lot of work to switch epoll wait vs mmap modes.
I think that's overkill; as soon as data is returned, you're going to be talking to the kernel in order to get it. Besides, leave something for userspace tcp stack implementations.
I'm bothered by the fact that the kernel will not be able to poll NIC or storage controller rings if userspace is doing the polling :(.
Yes, that's a concern. We have three conflicting requirements: - fast inter-thread IPC (or guest/host IPC) -> shared memory+polling- kernel multiplexing of hardware -> kernel interfaces + kernel poll / sleep
- composable interfaces that allow you to use the two methodsYou could use something like Flow Director to move interesting flows directly to the application, let the application poll those queues (and maybe tell the kernel if something interesting happens), while the kernel manages the other queues. It gets ugly very quickly.
[Prev in Thread] | Current Thread | [Next in Thread] |