Re: [Jackit-devel] Re: jack, PREEMPT_DESKTOP, delayed interrupts?

Ingo Molnar <[EMAIL PROTECTED]> writes: > - if everything fails and automatic latency tracing does not show > anything out of ordinary, then you could try to do "user-triggered > tracing" of jackd's critical path. This is more laborous to do, but > should pinpoint the latency reason in a p

Re: [Jackit-devel] Re: jack, PREEMPT_DESKTOP, delayed interrupts?

Ingo Molnar <[EMAIL PROTECTED]> writes: > i suspect the confusion comes from the API hacks i'm using: user-space > tracing is started/stopped via: > > gettimeofday(0,1); > gettimeofday(0,0); > > while 'jackd does not want to be scheduled' flag is switched on/off via: > > gettime

Re: 2.6.11-rc3-mm2

[direct reply bounced, resending via gmail] Andrew Morton <[EMAIL PROTECTED]> writes: > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/

Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> At around 55 seconds into the run, JACK got in trouble and throttled >> itself back to approximately the 30% limit (actually a little above). >> Then, around seco

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > pretty much the only criticism of the RT-CPU patch was that the global > sysctl is too rigid and that it doesnt allow privileged tasks to ignore > the limit. I've uploaded a new RT-CPU-limit patch that solves this > problem: > > http://redhat.com/~mingo/

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

Ingo Molnar <[EMAIL PROTECTED]> writes: > (My current thinking is that the default RT_CPU rlimit should be 0.) How about a kernel .config option allowing us to easily compile in a different default? That should tide over most of the audio users for the next 6 months or so until we get userspace

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > - exported the current RT-average value to /proc/stat (it's the last >field in the cpu lines) > e.g. the issue Con and others raised: privileged tasks. By default, the > root user will likely have a 0 rlimit, for compatibility. _But_ i can > easily

Re: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

Cal <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> I notice that JACK's call to mlockall() is failing. This is one >> difference between your system and mine (plus, my machine is UP). >> As an experiment, you might try testing with `ulimit -l unlimited&

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Nick Piggin <[EMAIL PROTECTED]> writes: > I'm a bit concerned about this kind of policy and breakage of > userspace APIs going into the kernel. I mean, if an app is > succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the > scheduler does something else, that could be undesirable in some >

Re: [ck] [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

Cal <[EMAIL PROTECTED]> writes: > Consideringthe amount and rate of work in progress, this may well be > no longer be pertinent, but I'm consistently getting an oops running > the basic jack_test3.2 with rt-limit-2.6.11-rc2-D7 on SMP (P3 993 x > 2). The oops and jacktest log are at >

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Nick Piggin <[EMAIL PROTECTED]> writes: > On Wed, 2005-01-26 at 20:31 -0600, Jack O'Quin wrote: >> Nick Piggin <[EMAIL PROTECTED]> writes: >> >> > I'm a bit concerned about this kind of policy and breakage of >> > userspace APIs going

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > >> But the important elements are lost. The standard provides a >> deterministic scheduling order, and a deterministic scheduling latency >> (of course this doesn't mean a great deal for Linux, but I think we're >

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > >> And finally, with rlimit support, is there any reason why lockup >> detection and correction can't go into userspace? Even RT throttling >> could probably be done in a userspace daemon. > > that is correct. Jac

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> > i'm wondering, couldnt Jackd solve this whole issue completely in >> > user-space, via a simple setuid-root wrapper app that does nothing else >> > but

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Peter Williams <[EMAIL PROTECTED]> writes: > > If the average usage rate is estimated over longer periods it will be > lower allowing lower limits to be used. Also if the task's own usage > rate estimates are used to test the limits then the limit can be lower. > > If the default limits can be mad

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

Con Kolivas <[EMAIL PROTECTED]> writes: > While it is not clear what form the final soft real time > implementation is, we should complete the partial implementation of > SCHED_ISO that is in 2.6.11-rc2-mm1. I finally had a chance to try this today. I applied a slightly different patch (2.6.11-r

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> Loading the realtime-lsm and then running with SCHED_FIFO *does* work >> as expected on this kernel. I should retry the test with *exactly* >> the expected patch sequence. What would that be? > &g

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

Con Kolivas <[EMAIL PROTECTED]> writes: > Sure enough I found the bug in less than 5 mins, and it would > definitely cause this terrible behaviour. > > A silly bracket transposition error on my part :P The corrected version works noticeably better, but still nowhere near as well as SCHED_FIFO. T

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

> Jack O'Quin wrote: >> The corrected version works noticeably better, but still nowhere near >> as well as SCHED_FIFO. The first run had a cluster of really bad >> xruns. The second and third were much better, but still with numerous >> small xruns. >>

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

Con Kolivas <[EMAIL PROTECTED]> writes: > Good work. Looks like you're probably right about the accounting. It > may be as simple as the fact that it is on the timer tick that we're > getting rescheduled and this ends up being accounted as more since the > accounting happens only at the scheduler

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo, I hope we can get past this anger and continue working together. We have too much to gain by cooperating. It would be a shame to let hurt feelings get in the way for either of us. > * Jack O'Quin <[EMAIL PROTECTED]> wrote: >> Well, this extremely long discussion st

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[trimming the Cc: list] > * Jack O'Quin <[EMAIL PROTECTED]> wrote: >> Remember when I asked how you handle changes to sizeof(struct rusage)? >> That was a serious question. I hope there's a solution. [...] Ingo Molnar <[EMAIL PROTECTED]> writes: > what d

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Bill Huey (hui) <[EMAIL PROTECTED]> writes: > Also, as media apps get more sophisticated they're going to need some > kind of access to the some traditional softirq facilities, possibily > migrating it into userspace safely somehow, with how it handles IO > processing such as iSCSI, FireWire, netw

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

> On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote: >> Is nobody responsible for figuring out what users need? I didn't >> realize kernel development had become so disconnected. Lee Revell <[EMAIL PROTECTED]> writes: > IMHO the requirements gathering

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > so forgive us this stubborness, it's not directed against you in person > or against any group of users, it's always directed at the problem at > hand. I think we can do the LSM thing, and if this problem comes up in > the future again, then maybe by that

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Peter Williams <[EMAIL PROTECTED]> writes: >>> If you have the source code for the programs then they could be >>> modified to drop the root euid after they've changed policy. Or >>> even do the > Paul Davis wrote: >> This is insufficient, since they need to be able to drop RT >> scheduling and

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

> Jack O'Quin wrote: >> Temporarily dropping privileges gains no security whatsoever. It is >> nothing more than a coding convenience. Peter Williams <[EMAIL PROTECTED]> writes: > Yes, to help avoid accidentally misusing the privileges. >> The program r

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Peter Williams <[EMAIL PROTECTED]> writes: > Paul Davis wrote: >> There are several kernel-side attributes that would make JACK better >> from my perspective: >> * better ways to acquire and release RT scheduling > > I'm no expert on the topic but it would seem to me that the mechanisms > ass

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

Ingo Molnar <[EMAIL PROTECTED]> writes: > i believe RT-LSM provides a way to solve this cleanly: you can make your > audio app setguid-audio (note: NOT setuid), and make the audio group > have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you > could have a finegrained per-app way of

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Werner Almesberger <[EMAIL PROTECTED]> writes: > [ Cc:s trimmed, added abiss-general ] > > Con Kolivas wrote: >> Possibly reiserfs journal related. That has larger non-preemptible code >> sections. > > If I understand your workload right, it should consist mainly of > computation, networking (?),

Re: [PATCH] [request for inclusion] Realtime LSM

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> OK, I reran with just 5 processes reniced from -10 to -5. On my >> system they were: events, khelper, kblockd, aio and reiserfs. In >> addition, I reniced loop0 fro

Re: [PATCH] [request for inclusion] Realtime LSM

> * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> --- kernel/sched.c~ Fri Dec 24 15:35:24 2004 >> +++ kernel/sched.c Wed Jan 12 23:48:49 2005 >> @@ -95,7 +95,7 @@ >> #define MAX_BONUS (MAX_USER_PRIO * PRIO_BONUS_RATIO / 100) >&g

Re: [PATCH] [request for inclusion] Realtime LSM

>> * Jack O'Quin <[EMAIL PROTECTED]> wrote: >>> One major problem: this `nice --20' hack affects every thread, not >>> just the critical realtime ones. That's not what we want. Audio >>> applications make very conscious choices which thread

Re: [PATCH] [request for inclusion] Realtime LSM

Mike Galbraith <[EMAIL PROTECTED]> writes: > At 07:14 PM 1/14/2005 -0600, Jack O'Quin wrote: >>Mike Galbraith <[EMAIL PROTECTED]> writes: >> >> > At 05:31 PM 1/13/2005 -0600, Jack O'Quin wrote: >> >>Yes. However, my tests have so far show

Re: [PATCH] [request for inclusion] Realtime LSM

> Ingo Molnar <[EMAIL PROTECTED]> writes: >> could you try the patch below? The above patch wasnt enough. With the >> patch below we turn off the starvation limits for nice --20 tasks only. >> This is still a hack only. If we cannot make nice --20 perform like >> RT-prio-1 then there's some probl

Re: [PATCH] [request for inclusion] Realtime LSM

Jack O'Quin <[EMAIL PROTECTED]> writes: > *** Terminated Sat Jan 15 18:15:13 CST 2005 *** > * SUMMARY RESULT > Total seconds ran . . . . . . : 300 > Number of clients . . . . . . :20 > Ports per client . . . . . . : 4 > Frames p

Re: [PATCH] [request for inclusion] Realtime LSM

> * Andrew Morton <[EMAIL PROTECTED]> wrote: > >> Still. It seems to be what we deserve if all that fancy stuff we have >> cannot address this very simple and very real-world problem. Ingo Molnar <[EMAIL PROTECTED]> writes: > please describe this "very simple and very real-world problem" in simp

Re: [PATCH] [request for inclusion] Realtime LSM

Andrew Morton <[EMAIL PROTECTED]> writes: > Matt Mackall <[EMAIL PROTECTED]> wrote: >> >> I think Chris Wright's last rlimit patch is more sensible and ready to >> go. > > I must say that I like rlimits - very straightforward, although somewhat > awkward to use from userspace due to shortsighted

Re: [PATCH] [request for inclusion] Realtime LSM

>> Andrew Morton <[EMAIL PROTECTED]> writes: >> > Does anyone have serious objections to this approach? > On Mon, Mar 07, 2005 at 11:30:57PM -0600, Jack O'Quin wrote: >> 1. is likely to introduce multiuser system security holes like the one >> created

Re: [PATCH] [request for inclusion] Realtime LSM

Matt Mackall <[EMAIL PROTECTED]> writes: > On Tue, Mar 08, 2005 at 09:39:24PM -0600, Jack O'Quin wrote: >> >> 4. is undocumented and has never been tested in any real music studios >> > >> > Well you'll have a bit to test it before it goes to Linu

Re: [PATCH] [request for inclusion] Realtime LSM

> * Jack O'Quin <[EMAIL PROTECTED]> wrote: >> According to the manpage, nice(2) is per-process not per-thread. That >> does not give the granularity we need. Ingo Molnar <[EMAIL PROTECTED]> writes: > the manpage is incorrect - sys_nice() is per-thread. (Btw.

Re: [PATCH] [request for inclusion] Realtime LSM

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> Is it possible to call sched_setscheduler() with a thread ID instead >> of a pid? That's what I really need. JACK sets and resets the thread >> priorities from

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

Cal <[EMAIL PROTECTED]> writes: > There's a collection of test summaries from jack_test3.2 runs at > > > Tests were run with iso_cpu at 70, 90, 99, 100, each test was run > twice. The discrepancies between consecutive runs (with same > par

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Cal wrote: > > SCHED_ISO > /proc/sys/kernel/iso_cpu . . .: 70 > /proc/sys/kernel/iso_period . : 5 > XRUN Count . . . . . . . . . : 110 > > vs > > SCHED_FIFO > XRUN Count . . . . . . . . . : 114 > XRUN Count . . . . . . . . . : 187 > > vs > > SCHED

Re: [PATCH] [request for inclusion] Realtime LSM

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> In the absence of any documentation, I'm guessing about storing the >> nice value in the priority field of the sched_param struct. But, I >> have not been abl

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > This patch for 2.6.11-rc1 provides a method of providing real time > scheduling to unprivileged users which increasingly is desired for > multimedia workloads. I ran some jack_test3.2 runs with this, using all the default settings. The results of three r

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> Con Kolivas <[EMAIL PROTECTED]> writes: >> >>>This patch for 2.6.11-rc1 provides a method of providing real time >>>scheduling to unprivileged users which increasingly is

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[including Rui Nuno Capela in cc: list] >> Con Kolivas <[EMAIL PROTECTED]> writes: >> >>>This patch for 2.6.11-rc1 provides a method of providing real time >>>scheduling to unprivileged users which increasingly is desired for >>>multimedia w

Re: [PATCH] [request for inclusion] Realtime LSM

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > >> i'm not suggesting that this is the way to go, it's just to test how >> nice--20 tasks would perform (on the hacked kernel). We still dont >> have this data, because in the other tests you tried, some >> non-hi

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> Try again with JACK 0.99.48. It's in CVS now, but you probably need >> this tarball to get around the dreaded SourceForge anon CVS lag... >> >> http://www.joq.us/jack/tarballs/jack-audio-

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Con Kolivas wrote: > > Here are my results with SCHED_ISO v2 on a pentium-M 1.7Ghz (all > powersaving features off): > > Increasing iso_cpu did not change the results. > > At least in my testing on my hardware, v2 is working as advertised. I > need results

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> Excellent. Judging by the DSP Load, your machine seems to run almost >> twice as fast as my 1.5GHz Athlon (surprising). You might want to try > > Not really surprising; the 2Mb cache makes this a dam

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> Outstanding. How do you get rid of that checkerboard grey >> background in the graphs? > >> Con Kolivas <[EMAIL PROTECTED]> writes: > Funny; that's the script you sent me so... be

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: >> Jack O'Quin wrote: >>> You're really getting hammered with those periodic 6 msec delays, >>> though. The basic audio cycle is only 1.45 msec. > Con Kolivas wrote: >> As you've already pointed

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Paul Davis <[EMAIL PROTECTED]> writes: >>That's discouraging about reiserfs. Is it version 3 or 4? Earlier >>versions showed good realtime responsiveness for audio testers. It >>had a reputation for working much better at lower latency than ext3. > > over on #ardour last week, we saw appalling

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

"Rui Nuno Capela" <[EMAIL PROTECTED]> writes: > OK. Here goes my fresh and newly jack_test4.1 test suite. It might be > still rough, as usual ;) Thanks for all your work on this fine test suite. > This phenomenon, so to speak, shows up as a sudden full increase of > DSP/CPU load after a few minu

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Peter Chubb <[EMAIL PROTECTED]> writes: >>>>>> "Jack" == Jack O'Quin <[EMAIL PROTECTED]> writes: > > Jack> Looks like we need to do another study to determine which > Jack> filesystem works best for multi-track audio recording and >

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Rui Nuno Capela wrote: >> My eyes can't find anything related, but you know how intuitive these >> things are ;) > > He means when using the SCHED_ISO patch. Then you'd have iso_cpu and > iso_period, which you have neither of so you are not using SCHED_ISO

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Ingo Molnar <[EMAIL PROTECTED]> writes: > just finished a short testrun with nice--20 compared to SCHED_FIFO, on a > relatively slow 466 MHz box: > this shows the surprising result that putting all RT tasks on nice--20 > reduced context-switch rate by 20% and the Delay Maximum is lower as > well.

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > As for priority support, I have been working on it. While the test > cases I've been involved in show no need for it, I can understand why > it would be desirable. Yes. Rui's jack_test3.2 does not require multiple realtime priorities, but I can point to

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Here's fresh results on more stressed hardware (on ext3) with > 2.6.11-rc1-mm2 (which by the way has SCHED_ISO v2 included). The load > hovering at 50% spikes at times close to 70 which tests the behaviour > under iso throttling. What version of JACK are

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > So let's try again, sorry about the noise: > > ==> jack_test4-2.6.11-rc1-mm2-fifo.log <== > * > XRUN Count . . . . . . . . . : 3 > Delay Maximum . . . . . . . . : 20161 usecs >

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Ingo Molnar <[EMAIL PROTECTED]> writes: > thanks for the testing. The important result is that nice--20 > performance is roughly the same as SCHED_ISO. This somewhat > reduces the urgency of the introduction of SCHED_ISO. I can see why you feel that way, but don't share your conclusion. First,

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> Neither run exhibits reliable audio performance. There is some low >> latency performance problem with your system. Maybe ReiserFS is >> causing trouble even with logging turned off. Perhaps

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: > [snip lots of valid points] >> suggest some things to try. First, make sure the JACK tmp directory >> is mounted on a tmpfs[1]. Then, try the test with ext2, instead of > > Looks like the tm

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Meanwhile, I have the priority support working (but not bug free), and > the preliminary results suggest that the results are better. Do I > recall someone mentioning jackd uses threads at different priority? Yes, it does. I'm not sure whether that mat

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Jack O'Quin <[EMAIL PROTECTED]> writes: > > I ran three sets of tests with three or more 5 minute runs for each > case. The results (log files and graphs) are in these directories... > > 1) sched-fifo -- as a baseline > http://www.joq.us/jack/benchmarks/

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Ingo Molnar <[EMAIL PROTECTED]> writes: > thanks for the testing. The important result is that nice--20 > performance is roughly the same as SCHED_ISO. This somewhat > reduces the urgency of the introduction of SCHED_ISO. Doing more runs and a more thorough analysis has driven me to a different c

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > There are two things that the SCHED_ISO you tried is not that > SCHED_FIFO is - As you mentioned there is no priority support, and it > is RR, not FIFO. I am not sure whether it is one and or the other > responsible. Both can be added to SCHED_ISO. I haven

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: >>>Second the patch I sent you is fine for testing; I was hoping you >>>would try it. What you can't do with it is spawn lots of userspace >>>apps safely SCHED_ISO with it - it will crash, but it not take down >>>your hard disk. I've had significantly better

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Jack O'Quin <[EMAIL PROTECTED]> writes: > These results are indistinguishable from SCHED_FIFO... Disregard my previous message, it was an idiotic mistake. The results were indistinguishable form SCHED_FIFO because they *were* SCHED_FIFO. I'm running everything again, this ti

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Jack O'Quin <[EMAIL PROTECTED]> writes: > Will post the correct numbers shortly. Sorry for the screw-up. Here they are... http://www.joq.us/jack/benchmarks/sched-isoprio http://www.joq.us/jack/benchmarks/sched-isoprio+compile I moved the previous runs to the sched-fifo* dir

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Ingo Molnar <[EMAIL PROTECTED]> writes: > just finished a short testrun with nice--20 compared to SCHED_FIFO, on a > relatively slow 466 MHz box: Has anyone done this kind of realtime testing on an SMP system? I'd love to know how they compare. Unfortunately, I don't have access to one at the m

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> I'll try building a SCHED_RR version of JACK. I still don't think it >> will make any difference. But my intuition isn't working very well >> right now, so I need more data. > >

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> First, only SCHED_FIFO worked reliably in my tests. In Con's tests >> even that did not work. My system is probably better tuned for low >> latency than

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

Con Kolivas <[EMAIL PROTECTED]> writes: > There were numerous bugs in the SCHED_ISO design prior to now, so it > really was not performing as expected. What is most interesting is > that the DSP load goes to much higher levels now if xruns are avoided > and stay at those high levels. If I push the

Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> It works great... >> >> http://www.joq.us/jack/benchmarks/rt_cpu_limit >> http://www.joq.us/jack/benchmarks/rt_cpu_limit+compile >> http://www.joq.us