[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] serial8250: too much work for irq4
Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> writes: > 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. I'll check that out, thanks. >> 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. For better or worse, it does. I guess a case could be made that any sane 8250-compatible chip, real or virtual, should behave like a 8250 when treated like a 8250. I.e. if told to go nice and slow, it better goes nice and slow. If it can also go very fast, it should have some extra knob for that. > 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. Perhaps we should discuss this with driver maintainers, just to make sure we're not missing anything here. > 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. Point. > 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. Just like with a real machine :) > 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. I'm afraid I don't. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |