| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] serial8250: too much work for irq4
Markus Armbruster writes ("Re: [Xen-devel] serial8250: too much work for irq4"):
> I see funny effects where serial output stalls until some input happens,
> but I don't know whether that's related, or whether xen-unstable has the
> same problem.
This is probably the bug that Anders Kaseorg reported on the 5th of
February which I tracked down to a pair of bugs in the Linux kernel's
serial driver, and therefore unrelated. See
http://lists.xensource.com/archives/html/xen-devel/2009-02/msg00372.html
and the surrounding thread.
> The 8250 driver makes the (reasonable) assumption that the chip operates
> at a limited speed. All real UARTs do. The comment next to the printk
> in drivers/serial/8250.c says "If we hit this, we're dead." Sounds
> scary, but I figure it's overstating the case. The loop executes
> holding a spin lock, but is limited to 256 iterations. The printk fires
> if we hit the limit and take the emergency exit. Still, I'm worried we
> hog the cpu for longer than is healthy, or that taking the emergency
> exit isn't as harmless as it looks to me so far.
I don't think that the general 8250 driver can reasonably make the
assumption that the chip's transfer speed is slow compared to the host
CPU clock. That register interface is sometimes used for very high
speed links.
The overall effect in your situation will be, I think, that:
* serial output will take priority over other demands on
the guest CPU, so long as any output is pending
* some CPU may be wasted with other VCPUs spinning on the lock
although in modern kernels the fallback to a sleep/wakeup
lock will kick in and avoid this being too much of a problem
The first of these effects isn't desirable but it's difficult to see a
good alternative.
Note that on many real systems sending a lot of output to the serial
port can cause CPU starvation - some years ago my (non-virtualised
Linux) colo machine had timekeeping trouble until I stopped the kernel
packet filter from complaining to the serial console. I imagine this
has been improved by now, but even so userspace (and users) of even
modern operating systems should be aware of these kind of problems and
not spew huge quantities of unacknowledged stuff to serial consoles.
We could rate limit the port to some speed according to the wall
clock, but the time intervals would have to be very short. With a
115200bps serial port, a character period is just under 90us. Even
limiting consecutive serial writes to a few dozen (32 say) would mean
that we need to set a timer every 2.8ms.
And the result of doing that would be that when the only thing which
is happening is that some data transfer is happening over an emulated
serial port, the transfer would be artificially limited to some
nominal speed.
Do you have any better ideas for how to trick the guest into making
better use of its CPU time, which will solve your use case without
imposing an artificial wall clock based speed limit ?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home