[LTP] LTP: futex_wake04 hangs forever on i386
Cyril Hrubis
chrubis@suse.cz
Wed Oct 10 14:05:50 CEST 2018
Hi!
> > Doing a simple math if you have serial line on 115200 it can transwer
> > about 11.5 bits in 100uS so yes we can easily overload serial connection
> > if we print messages that fast, so increasing the sleep 10x times sounds
> > only reasonable.
> >
> > On the other hand I guess that kernel shouldn't produce stalls just
> > because we write to serial too fast. I guess that the task writing to
> > serial should be sleeping in a waitqueue somewhere in kernel if it
> > attempts to write to a full serial buffer, which will effectivelly
> > slow down the writer and the test would work fine in this case...
>
> That is what happened, no ? Stack trace shows that possibly same process
> that had its execution interrupted by the time handler in a recent past
> (with a leftover frame pointer indicated by ? apic_timer_interrupt) also
> ran the handler for serial8250_interrupt() and that execution caused
> some dmesg warnings like:
>
> serial8250: too much work for irq
>
> which I had. I guess having the terminal with a smaller buffer would
> help here as well, since the calls to the interrupt handler would be
> more often and less time consuming (because of baud rate).
>
> Continuing, there was a software interrupt to flush serial 8250 contents
> and it took too long to flush to the device, causing the task, waiting
> on the line, to wait.
>
> HOWEVER, for this case, for example, every single byte written to a
> terminal memory mapped I/O register causes a VM_EXIT (in the host:
> cpu->kvm_run->exit_reason == 2), giving execution back to the QEMU vCPU
> (that had entered VM mode), that will schedule a function inside the
> emulation thread to deal with that I/O (for the virtualized serial HW
> being emulated) and calling the VM_ENTER again at some further point.
> This could make the interrupt handler even slower.
Ok, I guess that I understand why this is so slow, we emulate PC memory
mapped serial port and we go back and forth for each byte we write. And
I guess that we cannot do much about this.
Also I suppose that it could be "fixed" by switching to virtio serial
driver that should be able to read the whole buffer in one go.
--
Cyril Hrubis
chrubis@suse.cz
More information about the ltp
mailing list