artsd hanging with SCHED_FIFO

[Roger Larsson]

On Friday 19 September 2003 21.09, Matthias Kretz wrote:
> Hi,
>
> recently Stefan added the possibility to show DrKonqi if artsd crashes. And
> yesterday I thought, oh well I've never seen it yet...
>
> So I typed "killall -11 artsd" and my computer was gone - total lockup. I
> rebooted and thanks to reiserfs lost some .kde/share/config files once
> again. Recently I had lockups when shutting down KDE. I have the feeling
> that this is related.
>
> Here's my analysis and a patch that's definetly not ready for prime time:
>
> If artsd is idle the killall will work without problems, but if I have
> music playing (ogg or mp3) artsd will hang my system. So it seems that the
> other artsd threads are causing the problems. The main thread goes into the
> sighandler and drops SCHED_FIFO while the other threads are still
> SCHED_FIFO. If the other threads take full CPU for some reason: lockup.

Possibly they wants to communicate with the master...?

>
> With the patch I attached I cannot reproduce the problem anymore. It's
> calling pthread_kill_other_threads_np() in the sighandler - but the man
> page says that's Linux specific.
>
> You also might notice that I moved the SCHED_FIFO dropping code. I tried
> that because CPUUsage works using SIGALRM and the sighandler was being
> changed before dropping SCHED_FIFO - but it didn't have the desired effect
> of fixing the problem.
>
> A few questions:
> - Are there other ways to get rid of child threads?
> - Can I drop SCHED_FIFO on the child threads?

I do not think artsd can - priviliged.

> - Will the crashhandler be called for the child threads, too?
> - Is the sighandler for SIGALRM inherited by the child threads. I.e. do the
> child threads call CPUUsage::check()?

Looking at the code I would say that they need to add an instance of CPUUsage
themselves to get monitored.

> not directly related:
> - If I create two child threads in an aRts module and make 'em both use as
> much CPU as possible, CPUUsage will not detect the problem, right?

correct

>
> /me has the feeling we need an artswatchdog process...

artswrapper could be modified to do that

Attaching my rt_monitor (it could be merged with artswrapper!)
It runs as root and can drop priorities of processes. It uses a global
approach - total SCHED_FIFO/RR time over the limit => all
SCHED_FIFO/RR to SCHED_OTHER. It should probably only
affect processes (and their children) that asked for SCHED_FIFO/RR.

Related:
There has been two approaches on linux-kernel

1) SCHED_SOFTRR
Works as SCHED_RR but any process might request it.
But when to much time is used up by these processes they will run as 
SCHED_OTHER.

2) scheduler improvements - interactivity feedback
Processes that sleeps (periodically) are viewed as interactive and gets
a boost.

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rt_monitor.zip
Type: application/x-zip
Size: 6051 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20030920/afd660e8/attachment.bin>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia