Debugging audio artifacts caused by... a serial port? • Hacker News Board

Re: Debugging audio artifacts caused by... a serial port?

#31

Post by toast0 » Tue, Oct 29, 2024, 5:33 AM UTC

rcxdude wrote: post #20

toast0 wrote: post #13

Earlier quoted context omitted.

Too late for edit... But rereading the blog and references... I suspect if this was on real hardware, with a real 16550 UART, you'd have the same issue, but without the message about too many interrupts. You'd just have your logs backing up because you're writing more than 115kbaud, and then things that write logs become blocking. You'd need to figure that out by seeing what processes are blocked on what, rather than…

It's not clear from the thread whether the logging to the serial port was in the same thread as the audio processing. If it was, then it would be a problem either way. If it wasn't, then the fact that the irq is not premptable would mean that it will cause problems for all threads in the virtual case, but not in the real hardware case.

Even on a virtual machine, I'd expect the serial interrupt to only be routed to one vCPU; that shouldn't prevent execution on other vCPUs right? (especially if you've got more than 2)... but if your tasks happen to be cpu pinned to the cpu that's bogged down with serial interrupts...

Something message at a time would be so much more useful than byte at a time with outb (does the Linux driver do rep outb... would that actually help?)

Re: Debugging audio artifacts caused by... a serial port?

#32

Post by rcxdude » Tue, Oct 29, 2024, 10:49 AM UTC

PaulDavisThe1st wrote: post #29

rcxdude wrote: post #23

Earlier quoted context omitted.

I think in this case, unless they were running an RT kernel, it wouldn't have helped, since the interrupt hogging the CPU was non-preemptable. But it's good advice in general.

RT is in the mainline kernel now. Run with threaded_irqs, all interrupt handlers become preemptable (by default).

True, but that's very recent, and still not a default configuration. (And the message reported in the article was removed from the mainline kernel in 2018)

Re: Debugging audio artifacts caused by... a serial port?

#33

Post by rcxdude » Tue, Oct 29, 2024, 11:00 AM UTC

toast0 wrote: post #31

rcxdude wrote: post #20

Earlier quoted context omitted.

It's not clear from the thread whether the logging to the serial port was in the same thread as the audio processing. If it was, then it would be a problem either way. If it wasn't, then the fact that the irq is not premptable would mean that it will cause problems for all threads in the virtual case, but not in the real hardware case.

Even on a virtual machine, I'd expect the serial interrupt to only be routed to one vCPU; that shouldn't prevent execution on other vCPUs right? (especially if you've got more than 2)... but if your tasks happen to be cpu pinned to the cpu that's bogged down with serial interrupts... Something message at a time would be so much more useful than byte at a time with outb (does the Linux driver do rep outb... would that…

True, having multiple CPUs should help. Though in my experience it's quite easy in linux for one CPU stalled in the kernel to block quite a wide range of other tasks, presumably because of contended locks.

And yes, the better approach is to use a virtio type system which is designed for VM to host communication, but VM implementations tend to emulate lowest-common-denominator hardware for the highest compatibility (The 8250 is everywhere, basically every OS supports it and its interface is very commonly emulated even in modern hardware). The issue is, because it's ancient hardware, every tiny buffer is basically a full interrupt routine (checking flags and copying data), with multiple traps to the VM emulation of it. Doing something like rep outb would be only a minor optimisation on top of that (it already does the most significant thing of continuing to copy data in the interrupt routine until the flag is unset, instead of waiting for the interrupt to re-trigger for each chunk of data).

(On real hardware, doing something like DMA is the much better way to optimise this, but it's probably not a good emulation target because DMA controllers vary wildly from platform to platform)