3 ms·

> simply adding a kernel patch won’t fix all of the software That's tautologically true, but something like the RT preemption kernel patch is still a basic req

> simply adding a kernel patch won’t fix all of the software That's tautologically true, but something like the RT preemption kernel patch is still a basic requirement for a truly responsive system. Once that's merged, you then have buy-in for that use case and can start fixing all the things that are broken in user-space, as well. Additionally, there's a lot that can be fixed by simple tuning. There's no excuse for UI input locking up when a system is low on RAM, for example. Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority, so that (1) they're always responsive, no matter what, and (2) when the system starts thrashing, they can still grab enough of whatever system resources are available (RAM, CPU, device I/O), so that the user can survey the situation and kill the offending process. Linux distributors are dropping the ball here - this sort of system-wide tuning is their job!

acdha 8y ago
Developers could have used asynchronous interfaces for decades now and it would make the user experience substantially better with no kernel changes at all. There are reasons why they haven't but I don't see any reason to believe those will change with yet another real-time kernel patch. > Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority This approach is prone to priority-inversion and it doesn't help with the underlying problem that programmers have written tons of synchronous I/O all over the place and the call chains are often highly non-obvious. For example, most Linux desktop environments will freeze if you use an authentication provider which isn't instantly responsive and that prevents things like interacting with menus, closing windows, etc. because various low-level libraries do things like check settings which at some point does something like getting your list of groups, which is normally very fast because it's cached. I got some patches into pam_ldap years ago to set socket-level timeouts so it would recover from something like a single socket error but the better solution would be fewer dependencies and interfaces which don't have tons of different things happening on a single thread.
- zozbot123 8y ago
  > This approach is prone to priority-inversion Priority inversion is one of the main things that are addressed by the PREEMPT_RT patchset - without a fix to the priority inversion problem, you don't really have a RT system. Aside from that, I agree that we should move towards having async interfaces as the default whenever slow I/O is a realistic possibility. I'm not sure how many people actually use something like PAM-LDAP, though.

acdha 8y ago

Developers could have used asynchronous interfaces for decades now and it would make the user experience substantially better with no kernel changes at all. There are reasons why they haven't but I don't see any reason to believe those will change with yet another real-time kernel patch. > Any tasks that are critical to input on the system's console-like channel (whatever that is - it might be a serial console, UI graphics, a network connection or even an audio input subsystem plus some speech-recognition AI) should be running with elevated priority This approach is prone to priority-inversion and it doesn't help with the underlying problem that programmers have written tons of synchronous I/O all over the place and the call chains are often highly non-obvious. For example, most Linux desktop environments will freeze if you use an authentication provider which isn't instantly responsive and that prevents things like interacting with menus, closing windows, etc. because various low-level libraries do things like check settings which at some point does something like getting your list of groups, which is normally very fast because it's cached. I got some patches into pam_ldap years ago to set socket-level timeouts so it would recover from something like a single socket error but the better solution would be fewer dependencies and interfaces which don't have tons of different things happening on a single thread.

zozbot123 8y ago
> This approach is prone to priority-inversion Priority inversion is one of the main things that are addressed by the PREEMPT_RT patchset - without a fix to the priority inversion problem, you don't really have a RT system. Aside from that, I agree that we should move towards having async interfaces as the default whenever slow I/O is a realistic possibility. I'm not sure how many people actually use something like PAM-LDAP, though.