Re: SCHED_SOFTRR patch (memory lock?)

[Roger Larsson <roger.larsson@skelleftea.mail.telia.com>]

On Thursday 07 August 2003 18.31, Takashi Iwai wrote:
> At Thu, 7 Aug 2003 16:59:03 +0100,
>
> Daniel Phillips wrote:
> > > Under 2.6.0-test1 based kernels I have experienced quite a lote of
> > > drop-outs with XMMS playing mp3's with a moderate load, however, when
> > > run as root (with SCHED_RR) I encountered no drop-outs at all.  When
> > > using SOFTRR under I had very choppy playback when the machine was
> > > under load. It was a constant jittering more than intermittent
> > > drop-outs.
> >
> > According to me, this should not happen, since your cpu usage is well
> > below what is supposed to be the cutoff for the realtime slice.  I've
> > only seen one report like yours, where SOFTRR isn't working as intended. 
> > On the other hand, I've missed a lot of lkml traffice lately, so there
> > could be more.
>
> looking at the source code of xmms and found that xmms OSS output
> plugin behaves differently if the process is SCHED_RR.
> when xmms is started with SCHED_RR, it won't create an (another) audio
> thread.  perhaps this explains also the difference found in some
> cases.
>
> well, i'm not 100% sure about this theory, now needs to practice :)
> please try to turn off the check of SCHED_RR in
> xmms/Output/OSS/audio.c, something like:
>
>         realtime = xmms_check_realtime_priority();
>
> replaced with
>
> 	realtime = 0;

Another possibility - will XMMS lock its memory from swapping when running as 
root? (Or are there any special allocation/IO rule for root?)

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden