Re: serial8250: too much work for irq4

[Markus Armbruster <armbru@redhat.com>]

Ian Jackson <Ian.Jackson@eu.citrix.com> 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.