Red Hat's "Stalld" Thread Stall Detector + Booster Sees New Updates

[phoronix]

Phoronix: Red Hat's "Stalld" Thread Stall Detector + Booster Sees New Updates

Back in August we reported on Red Hat engineers developing Stalld as a new Linux service for detecting stalled threads and also allowing select threads to be boosted based on policy. In the months since Stalld continues to be developed and recently saw new releases...

http://www.phoronix.com/scan.php?page=news_item&px=New-Stalld-Releases

[milkylainen]

I'd give it about 5 more days before the all-inclusive monster comes looking for services to assimilate...

[skeevy420]

So in anticipation of my bass arriving I installed Fedora Jam yesterday and that makes me wonder how this will work with real time applications. Like, this won't boost a stalled thread which will in turn accidentally desync my real time DSP effects or anything like that?

[tildearrow]

I hope there will be a command line manager, it would be named StallMan.

I’d just like to interject for a moment. What you’re referring to as StallMan, is, in fact, GNU/StallMan, or as I’ve recently taken to calling it, GNU plus StallMan.

[k1e0x]

Systemd's implementation of the 486 Turbo Button.

2% of system resources lost running stalld, 1% gained by boosting. profit.

[muncrief]

I have never understood the purpose of this.

If the chosen scheduler is working correctly, and a thread is stalled, isn't that the way it's supposed to be? And if the scheduler isn't working correctly, shouldn't the scheduler be fixed? Finally, if the scheduler is working correctly and you don't want a thread stalled, shouldn't you change the priority of the problem program, or change the type of scheduler?

I'm just an old retired engineer, and not a Linux kernel developer, so I'm sure I must be missing something. So if someone could explain it to me I would appreciate it.

[k1e0x]

I have never understood the purpose of this.

If the chosen scheduler is working correctly, and a thread is stalled, isn't that the way it's supposed to be? And if the scheduler isn't working correctly, shouldn't the scheduler be fixed? Finally, if the scheduler is working correctly and you don't want a thread stalled, shouldn't you change the priority of the problem program, or change the type of scheduler?

I'm just an old retired engineer, and not a Linux kernel developer, so I'm sure I must be missing something. So if someone could explain it to me I would appreciate it.

This sounds correct to me. I think this has to do with desktop'ization of Linux where they want some kind of popup? idk. Doing more stuff doesn't sound any faster to me.

Also if your program keeps dying, restarting it and finding new ways to restart it *isn't* the answer. You need to find out why it's dying, debug it and fix it. "Just reboot it" is Redmond talk..

When failing process become normalized you are just going to get more failing process.

[F.Ultra]

This sounds correct to me. I think this has to do with desktop'ization of Linux where they want some kind of popup? idk. Doing more stuff doesn't sound any faster to me.

Also if your program keeps dying, restarting it and finding new ways to restart it *isn't* the answer. You need to find out why it's dying, debug it and fix it. "Just reboot it" is Redmond talk..

When failing process become normalized you are just going to get more failing process.

Actually I would claim that 99% of all server admins out there regardless of OS is going the restart route a few times before going the debug->fix path, mostly due to the fact that restart actually fixes most problems so it's the quick solution, and secondly due to them not being able to perform the fixing since they are either not also developers or that the developers in house have a dev-queue that is at least 6 months long.

When DJ Bernstein made automatic deamon restarting mainstream 2001 with his deamontools, tons of old hat unix admins found it useful. It's only now when systemd also incorporated it that it suddenly become a problem.

[Alex/AT]

I have never understood the purpose of this.

From my PoV, you are absolutely right in that. If the scheduler works correctly, there should be no 'stalled threads'. If it does not, it should be fixed.
Randomly prioritizing threads 'empirically' detected to be 'stalled' can only make things worse because it will have adverse and less predictable effects on the other threads in attempt to mitigate scheduling issue. So you will get dozens of misscheduled threads instead of one.

[Volta]

k1e0x

In your slowlaris and BSD world you have to restart everything manually? Maybe in ten years you will catch up to current Linux, but I doubt.