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
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
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
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
4 matches
Mail list logo
