On Wed, May 24, 2023 at 12:48:51PM +0200, Thorsten Leemhuis wrote: > On 23.05.23 21:44, Sergey Organov wrote: > > "Linux regression tracking (Thorsten Leemhuis)" > > <regressions@xxxxxxxxxxxxx> writes: > > > >> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting > >> for once, to make this easily accessible to everyone. > >> > >> Stefan, was this regression ever solved? It doesn't look like it, but > >> maybe I'm missing something. > >> > >> If it wasn't solved: what needs to be done to get this rolling again? > > > > Not Stefan, > > Thx to both you and Stefan for the update. > > > but as far as I can tell, the problem is that on Stefan's > > build the kernel has rather large periods of interrupts being disabled, > > so any attempt to decrease IRQs frequency from UART by raising FIFO IRQ > > threshold causes "regression" that manifests itself as missing > > characters on receive. I'm not sure if it's tuning FIFO level that is in > > fact a regression in this case. > > Not totally sure, but I guess Linus stance in this case would be along > the lines of "commit 7a637784d517 made an existing issue worse; either > the people involved in it fix it, or we revert that commit[1], as it's > causing a regression". At least we *iirc* had situations he handled like > that. > > [1] of course unless a revert would cause regressions for others -- > which i guess might be the case here, as that was added in 5.18 already. > So let's not bring Linus in. Well in my eyes this regression is in the same league as: That patch over made a driver use some more memory and on my (memory limited) machine this makes the difference to trigger an OOM. You could apply this to pretty much any patch that increases the memory foot print / latency / cpu usage. (TL;DR: I agree to not revert the patch under discussion for this reason.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
