Bugzilla – Bug 1218153
reduce SERIAL_8250_RUNTIME_UARTS?
Last modified: 2024-01-22 15:26:19 UTC
CONFIG_SERIAL_8250_RUNTIME_UARTS is currently set to 32 which leads to 32 /dev/ttyS*. The upstream default is 4. Is there a need to pre-create that many nodes? I noticed that it clutters the `systemd-analyze blame` quite a bit when looking for boot times. Maybe reduce it back to 4? Users that really need that many ports can set 8250.nr_uarts=32 on the kernel command line as documented upstream: https://github.com/torvalds/linux/blob/master/drivers/tty/serial/8250/Kconfig
The git log shows two changes: - Increased from 4 to 8 at commit f7e291e1bb6a in year 2008: "support more than 4 serial ports (FATE#303314)" - Increased from 8 to 32 at commit 85c87e3ee0de in year 2010: "bnc#652954: increase the number of possible and default uarts for users with multi-port serial cards for the i386 and x86-64 default configs" So there were reasons to increase, although it's not sure whether those are still valid nowadays.
Can we give a try? After all there's always the 8250.nr_uarts=32 module parameter for those special cases that need it. Maybe it didn't exist back then.
(In reply to Ludwig Nussel from comment #2) > Can we give a try? After all there's always the 8250.nr_uarts=32 module > parameter for those special cases that need it. Maybe it didn't exist back > then. We can try, but could you check whether reducing it would really give a significant benefit beforehand?
What's significant? :-) Yes, having 8250.nr_uarts=4 makes the systemd-analyze blame output much more readable.
I meant significant performance boost or such. Is it only about the readability of systemd-analyze, after all?
If there's a benefit it's within normal jitter, at least on the rpi400 I'm testing this on. So yeah, it's mostly to avoid this distraction. After all the current setting is a deviation from default upstream setting for apparently only some very specific corner case.
FWIW, the initial increase to 8 was requested from IBM at that time, even though the kernel command line option was already available. This was for the cash register machines that need to manage multiple serial UARTs.
OK, I pushed the changes to PR for master branch now. CONFIG_SERIAL_8250_RUNTIME_UARTS=4 for all configs now.
I have only two serial ports in my desktop but for practical reasons they are ttyS4 and ttyS5. (It was easier to find a PCI-E x1 card with two serial ports than a bracket needed to use those from motherboard controller.) Is this change going to mean that from now on I'll have to add the command line parameter? Not that I would find that too much of a hassle but once this change reaches Tumbleweed kernel, it will mean that anyone with a similar setup will suddenly lose their serial ports without any warning and without a clue what happened and why. (For the record, am I the only one who finds the "it will make the output of one specific utility nicer" argument rather weak?)
Yeah, changing the config would break use cases like yours. So I'm not sure whether this is really good to go. There seem actual valid use cases. I'll delete my PR for now. Let's keep discussing here how to handle further.
I'm sure there are setups with extra serial cards but how common is that, esp for TW anymore? So yes, those who have special setups need to set module parameters, just like on The main argument is that we might deviate from an upstream setting to cater for some rather exotic use cases. Funnily enough raising the setting was declined upstream in 2010, asking downstream to change the setting instead. Quite backwards. https://www.spinics.net/lists/linux-serial/msg03031.html Weird that we still have components that are that static. In a world full of VMs etc I would have expected only the devices nodes to exist that actually, well, exist :-) Anyway, feel free to do whatever.
I don't dare to guess how frequent it is but I wouldn't be really surprised if many of those who need a serial port (an actual one) for whatever reason were using an add-on card (for the same reason as me). But you are missing the important point: such users do exist and if we go with the change as suggested, in few weeks their serial port suddenly stops working without any warning and without any clue what happened and why. And I'm not really convinced that the reasoning presented so far does justify exposing our users - even if just a minority - to such experience. For the record: it's not about me, I can simply add a command line parameter to my config and go on, I already have few of them after all. But that's only because I was warned by seeing this pull request. Others would not be so lucky.