Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
We don't use signalfd in upstream QEMU. Instead, we always emulate it.
With an extra thread -> so an extra context switch.
We don't use an extra thread. We just install a signal handler that
writes to a pipe. At best, the added overhead is that we get EINTRs
more often but this is something we already handle.
Oh okay. But signal delivery is slow; for example the FPU needs to be
reset.
I'm not sure signalfd really buys us much. To emulate it requires
writing a bunch more data to the pipe. When writing more than 1 byte,
we have to worry about whether there's a partial write because the
pipe buffers full). We also have to make sure to read from the fd in
properly sized chunks.
Then we can use one byte writes (and reads) when signalfd is not
available. 128 byte pipe read/writes should always be atomic on Linux
though, likely on other OSes too.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
