From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXQAY-0000Dk-21 for qemu-devel@nongnu.org; Fri, 26 Sep 2014 03:42:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXQAP-0004Py-15 for qemu-devel@nongnu.org; Fri, 26 Sep 2014 03:42:22 -0400 Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:38053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXQAO-0004PL-Sy for qemu-devel@nongnu.org; Fri, 26 Sep 2014 03:42:12 -0400 Received: by mail-qc0-f178.google.com with SMTP id x13so6187523qcv.23 for ; Fri, 26 Sep 2014 00:42:07 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <542518CA.9020209@redhat.com> Date: Fri, 26 Sep 2014 09:42:02 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1411665709-2052-1-git-send-email-famz@redhat.com> <1411665709-2052-3-git-send-email-famz@redhat.com> <542470E4.6060402@redhat.com> <20140926012351.GA1680@fam-t430.nay.redhat.com> In-Reply-To: <20140926012351.GA1680@fam-t430.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] iohandler: Add Linux implementation of iohandler GSource List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi Il 26/09/2014 03:23, Fam Zheng ha scritto: > > Also, as an extra optimization perhaps you can make a second list with > > iohandlers that were modified or have a read_poll handler, and only call > > iohandler_get_events on that one. > > Sounds good, but I need to benchmark it to tell :) > > There isn't a lot of computation if there is no read_poll. > > > Perhaps this together lowers the cost of epoll enough to more easily > > reach the break-even point. > > Dynamic swithing between ppoll and epoll shoudn't be hard to implement, but I'm > not sure how to write the condition. Perhaps just a count of the number of polled file descriptors. > Anyway, do you think it is a good idea? It depends. I think first of all we need to profile it for low file descriptor counts, and see if obvious sources of overhead stand out either in QEMU or in the kernel... There's time anyway, since we also need a Win32 implementation. Paolo