[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Threa

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU
Date: Mon, 29 Mar 2010 23:31:44 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]