[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a
Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot.
Sun, 10 Feb 2008 11:26:06 +0000
On Sunday 10 February 2008, Blue Swirl wrote:
> On 2/9/08, H. Peter Anvin <address@hidden> wrote:
> > Blue Swirl wrote:
> > >> If you look at the patch, there are no timing dependencies; the only
> > >> parameter is the depth of the virtual queue. The exhaustion is
> > >> completely controlled by target OS access patterns.
> > >
> > > Thanks, this clarified the difference. But I'll rephrase my original
> > > comment:
> > >
> > > The patch looks OK, but the simulated FIFO exhaustion should benefit
> > > all devices, as
> > > discussed here:
> > > http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html
> > The difference is you *can't* do that in a general layer.
> What makes you think that is impossible?
IIUC the proposed patch makes the serial driver return an empty FIFO exactly
once, them immediately continue receiving data. Throughput should be
approximately the same, you've just got a bit of extra overhead to process
the additional interrupts. This is very different to the previous patch
which did time-based throughput limiting.
You can't do this in generic code because there's no way to guess when the
guest os has seen the FIFO empty condition. The best you can do is pause for
some arbitrary length of time, which is both unreliable (the guest OS may not
have got to far enough yet, especially if the host machine is heavily
loaded), and has a significant negative impact on throughput.
> Also win2k install hack in ide.c seems to be related to this problem,
> so even more generic solution would be desirable.
IIUC the win2k hack is an actual timing problem. The win2k IDE drivers are
buggy, and fall over if the drive responds too soon.