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