From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 05/24] compatfd is included before, and it is compiled unconditionally Date: Thu, 01 Oct 2009 16:44:00 +0200 Message-ID: <4AC4C030.5000004@redhat.com> References: <6e46fe952ba8d1896e3cab5b24232828d3f827a9.1253272938.git.quintela@redhat.com> <20090922131901.GA22109@infradead.org> <20090922133438.GA12443@infradead.org> <4AC4BB4E.2000906@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Juan Quintela , Christoph Hellwig , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29104 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754627AbZJAOoL (ORCPT ); Thu, 1 Oct 2009 10:44:11 -0400 In-Reply-To: <4AC4BB4E.2000906@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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. hmm, pipe(7) says writes smaller than the pipe buffer size are atomic: O_NONBLOCK enabled, n <= PIPE_BUF If there is room to write n bytes to the pipe, then write(2) succeeds immediately, writing all n bytes; otherwise write(2) fails, with errno set to EAGAIN. so it seems this practice has been blessed by posix. > 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? > The same is generally true for eventfd. eventfd emulation will also never get partial writes. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.