linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* SCHED_SOFTRR patch
@ 2003-07-28 20:27 Steven Newbury
  2003-08-07 15:59 ` Daniel Phillips
  0 siblings, 1 reply; 5+ messages in thread
From: Steven Newbury @ 2003-07-28 20:27 UTC (permalink / raw)
  To: davidel; +Cc: linux-kernel

I personally see your SCHED_SOFTRR as the correct solution for multimedia
applications.  But as it is currently tuned I have been unable to get it to
work adequately with a relatively undemanding program, XMMS.  I say undemanding
because XMMS only uses about 2-4% CPU time on my test machine (P3/933MHz) when
playing mp3's.

While testing SCHED_SOFTRR with XMMS I had to modify XMMS slightly since it
usually checks for uid 0 before enabling SCHED_RR.

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.

I have been using a 2.6.0-test2-O10int based kernel in my latest tests.  

With 2.6.0-test2-O10int it is very hard to get drop-outs unless I run it with
SCHED_SOFTRR!  The jitteriness is gone but a moderate load causes dropouts,
much like non SCHED_RR on 2.6.0-test1 based kernels.  SCHED_RR still runs
perfectly though.  It could be that SCHED_SOFTRR is being too "tight" with the
CPU time it is giving the Real-Time thread.

I have tried various values for the SCHED_TS_KSOFTRR, MIN_SRT_TIMESLICE,
MAX_SRT_TIMESLICE constants, but have been as yet unable to find values that
produce a good result.

The lattest.c program does show that SOFT_RR is working as does top which shows
RT priority for XMMS.


=====
Steve

__________________________________________________
Yahoo! Plus - For a better Internet experience
http://uk.promotions.yahoo.com/yplus/yoffer.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_SOFTRR patch
  2003-07-28 20:27 SCHED_SOFTRR patch Steven Newbury
@ 2003-08-07 15:59 ` Daniel Phillips
  2003-08-07 16:31   ` Takashi Iwai
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Phillips @ 2003-08-07 15:59 UTC (permalink / raw)
  To: Steven Newbury, davidel; +Cc: linux-kernel

On Monday 28 July 2003 21:27, Steven Newbury wrote:
> While testing SCHED_SOFTRR with XMMS I had to modify XMMS slightly since it
> usually checks for uid 0 before enabling SCHED_RR.

Oh good, then you won't have any problem with modifying the kernel to put in a 
printk or two ;-)

> 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.

What kind of system is this?  Is it a laptop with speedstep?

Regards,

Daniel


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_SOFTRR patch
  2003-08-07 15:59 ` Daniel Phillips
@ 2003-08-07 16:31   ` Takashi Iwai
  2003-08-07 18:05     ` SCHED_SOFTRR patch (memory lock?) Roger Larsson
  0 siblings, 1 reply; 5+ messages in thread
From: Takashi Iwai @ 2003-08-07 16:31 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Steven Newbury, davidel, linux-kernel

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;


-- 
Takashi Iwai <tiwai@suse.de>		SuSE Linux AG - www.suse.de
ALSA Developer				ALSA Project - www.alsa-project.org

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_SOFTRR patch (memory lock?)
  2003-08-07 16:31   ` Takashi Iwai
@ 2003-08-07 18:05     ` Roger Larsson
  2004-01-13 19:48       ` Davide Libenzi
  0 siblings, 1 reply; 5+ messages in thread
From: Roger Larsson @ 2003-08-07 18:05 UTC (permalink / raw)
  To: Takashi Iwai, Daniel Phillips; +Cc: Steven Newbury, davidel, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: SCHED_SOFTRR patch (memory lock?)
  2003-08-07 18:05     ` SCHED_SOFTRR patch (memory lock?) Roger Larsson
@ 2004-01-13 19:48       ` Davide Libenzi
  0 siblings, 0 replies; 5+ messages in thread
From: Davide Libenzi @ 2004-01-13 19:48 UTC (permalink / raw)
  To: Roger Larsson
  Cc: Takashi Iwai, Daniel Phillips, Steven Newbury, Linux Kernel Mailing List

On Thu, 7 Aug 2003, Roger Larsson wrote:

> 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?)

Gee, it was 100F last time I saw this thread :-)
Yes, xmms behave in two completely different ways depending on the fact 
that it is or it is not running RR. With RR it writes directly to the dsp, 
while w/out it creates a thread that handles an output buffer. Then thread 
then does write to the dsp when the buffer has something to be written.




- Davide



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-01-13 19:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-28 20:27 SCHED_SOFTRR patch Steven Newbury
2003-08-07 15:59 ` Daniel Phillips
2003-08-07 16:31   ` Takashi Iwai
2003-08-07 18:05     ` SCHED_SOFTRR patch (memory lock?) Roger Larsson
2004-01-13 19:48       ` Davide Libenzi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).