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: [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'. > > I went for the panic retraction o

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

Jack O'Quin wrote: You seem to have eliminated the mlock() failure as the cause of this crash. It should not have caused it anyway, but it *was* one noticeable difference between your tests and mine. Since do_page_fault() appears in the backtrace, that is useful to know. The other big difference

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

Ingo Molnar wrote: * Peter Williams <[EMAIL PROTECTED]> wrote: Oops, after rereading the patch, a task that set its RT_CPU_RATIO rlimit to zero wouldn't be escaping the mechanism at all. It would be suffering maximum throttling. [...] my intention was to let 'limit 0' mean 'old RT semantics' - i

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

Ingo Molnar wrote: * Peter Williams <[EMAIL PROTECTED]> wrote: Oops, after rereading the patch, a task that set its RT_CPU_RATIO rlimit to zero wouldn't be escaping the mechanism at all. It would be suffering maximum throttling. [...] my intention was to let 'limit 0' mean 'old RT semantics' - i

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

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'. I went for the panic retraction on the first report when I saw the failures i

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

Please ignore that, I've just started looking through the log properly. cheers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://w

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

Ingo Molnar wrote: [...] the -D7 patch available from the usual place: Hi, 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 an

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 feature, -D7

i've uploaded a simple utility to set the RT_CPU rlimit, called execrtlim: http://redhat.com/~mingo/rt-limit-patches/ execrtlim can be used to test the rlimit, e.g.: ./execrtlim 10 10 /bin/bash will spawn a new shell with RLIMIT_RT_CPU curr/max set to 10%/10%. on older kernels the utility

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

* Peter Williams <[EMAIL PROTECTED]> wrote: > Oops, after rereading the patch, a task that set its RT_CPU_RATIO > rlimit to zero wouldn't be escaping the mechanism at all. It would be > suffering maximum throttling. [...] my intention was to let 'limit 0' mean 'old RT semantics' - i.e. 'no RT C