Re: [PATCH 05/24] compatfd is included before, and it is compiled unconditionally

From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 05/24] compatfd is included before, and it is compiled unconditionally
Date: Thu, 01 Oct 2009 11:50:41 -0500	[thread overview]
Message-ID: <4AC4DDE1.1070803@codemonkey.ws> (raw)
In-Reply-To: <4AC4C030.5000004@redhat.com>

Avi Kivity wrote:
> On 10/01/2009 04:23 PM, Anthony Liguori wrote:
>> Juan Quintela wrote:
>>> Discused with Anthony about it.  signalfd is complicated for qemu
>>> upstream (too difficult to use properly),
>>
>> It's not an issue of being difficult.
>>
>> To emulate signalfd, we need to create a thread that writes to a pipe 
>> from a signal handler.  The problem is that a write() can return a 
>> partial result and following the partial result, we can end up 
>> getting an EAGAIN.  We have no way to queue signals beyond that point 
>> and we have no sane way to deal with partial writes.
>
> pipe buffers are multiples of of the signalfd size.  As long as we 
> read and write signalfd-sized blocks, we won't get partial writes.  
> It's true that depending on an implementation detail is bad practice, 
> but this is emulation code, and if helps simplifying everything else, 
> I think it's fine to use it.

That's a pretty hairy detail to rely upon..

>> Instead, how we do this in upstream QEMU is that we install a signal 
>> handler and write one byte to the fd.  If we get EAGAIN, that's fine 
>> because all we care about is that at least one byte exists in the 
>> fd's buffer.  This requires that we use an fd-per-signal which means 
>> we end up with a different model than signalfd.
>>
>> The reason to use signalfd over what we do in upstream QEMU is that 
>> signalfd can allow us to mask the signals which means less EINTRs.  I 
>> don't think that's a huge advantage and the inability to do backwards 
>> compatibility in a sane way means that emulated signalfd is not 
>> workable.
>
> signalfd is several microseconds faster than signals + pipes.  Do we 
> have so much performance we can throw some of it away?

Do we have any indication that this difference is actually observable?  
This seems like very premature optimization.

>> The same is generally true for eventfd.
>
> eventfd emulation will also never get partial writes.

But you cannot emulate eventfd faithfully because eventfd is supposed to 
be additive.  If you write 1 50x to eventfd, you should be able to read 
a set of integers that add up to 50.  If you hit EAGAIN in a signal 
handler, you have no way of handling that.

As I said earlier, the better thing to do is have a higher level 
interface that has a subset of the behavior of eventfd/signalfd that we 
can emulate correctly.

Regards,

Anthony Liguori