From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NwLcv-0005wN-G8 for qemu-devel@nongnu.org; Mon, 29 Mar 2010 16:32:01 -0400 Received: from [140.186.70.92] (port=43313 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwLct-0005uw-Ak for qemu-devel@nongnu.org; Mon, 29 Mar 2010 16:32:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NwLcr-000502-F8 for qemu-devel@nongnu.org; Mon, 29 Mar 2010 16:31:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42964) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwLcq-0004zA-DT for qemu-devel@nongnu.org; Mon, 29 Mar 2010 16:31:57 -0400 Message-ID: <4BB10E30.70908@redhat.com> Date: Mon, 29 Mar 2010 23:31:44 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU References: <1269535420-31206-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1269535420-31206-10-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <4BB04A59.1040204@linux.vnet.ibm.com> <4BB0C09D.7090204@linux.vnet.ibm.com> In-Reply-To: <4BB0C09D.7090204@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ericvh@gmail.com, jvrao , "Aneesh Kumar K.V" , qemu-devel@nongnu.org On 03/29/2010 06:00 PM, Anthony Liguori wrote: > > In qemu, we tend to prefer state-machine based code. > > There are a few different models that we have discussed at different > points: > > 1) state machines with a thread pool to make blocking functions > asynchronous (what we have today) > > 2) co-operative threading > > 3) pre-emptive threading > > All three models are independent of making device models re-entrant. > In order to allow VCPU threads to run in qemu simultaneously, we need > each device to carry a lock and for that lock to be acquired upon any > of the public functions for the device model. > > For individual device models or host services, I think (3) is probably > the worst model overall. I personally think that (1) is better in the > long run but ultimately would need an existence proof to compare > against (2). (2) looks appealing until you actually try to have the > device handle multiple requests at a time. Sooner or later nature and the ever more complicated code will force us towards (3). As an example, we've observed live migration to throttle vcpus when sending a large guest's zeroed memory over; the bandwidth control doesn't kick in since zero pages are compressed, so the iothread spends large amounts of time reading memory. We could fix this by yielding every so often (and a patch will be posted soon), but it remains an issue. We have too much work in the I/O thread and that defers I/O completion and timers. > For virtio-9p, I don't think (1) is much of a burden to be honest. In > particular, when the 9p2000.L dialect is used, there should be a 1-1 > correlation between protocol operations and system calls which means > that for the most part, there's really no advantage to threading from > a complexity point of view. But if those system calls are blocking, you need a thread? On a philosophical note, threads may be easier to model complex hardware that includes a processor, for example our scsi card (and how about using tcg as a jit to boost it :) -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.