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
|
Home