> At 12:12 AM 7/14/2003 -0700, Davide Libenzi wrote:
> >On Mon, 14 Jul 2003, Mike Galbraith wrote:
> > > While testing, I spotted something pretty strange. It's not specific to
> > > SCHED_SOFTRR, SCHED_RR causes it too. If I fire up xmms's gl visualization
> > > with either policy, X stops getting enough sleep credit to stay at a usable
> > > priority even when cpu usage is low. Fully repeatable weirdness. See
> > > attached top snapshots.
> >
> >RT tasks are pretty powerfull and should not be used to run everything ;)
> >What I was seeking with this patch was 1) deterministic latency 2) stave
> >protection.
>
> Yes, I know. I only fired up the cpu hog as a test to see that the
> protection would kick in. I did do that too though, ran _everything_...
> the whole X/KDE beast SCHED_SOFTRR for grins :)
>
> I should have reported the strangeness in a different thread, it has
> nothing to do with your patch.
Did you try the skip resistance test by running XMMS alone with audio ?
Also, trying the whole player running with SOFTRR does not match the
effective use MM apps will do of it. Usually inside MM apps the data
decoder (that might suck CPU) lives in another thread and the thread that
is actually responsible for timings simply fetch the prepared data.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/