[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: artsd hanging with SCHED_FIFO
From:       Roger Larsson <roger.larsson () skelleftea ! mail ! telia ! com>
Date:       2003-09-19 22:18:44
[Download RAW message or body]

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

["rt_monitor.zip" (application/x-zip)]

_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia


[prev in list] [next in list] [prev in thread] [next in thread]