[lkml]   [2005]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

* Jack O'Quin <> wrote:

> >> The equivalent rlimits experiment probably requires:
> >>
> >> (1) editing /etc/security/limits.conf
> >> (2) shutting everything down
> >> (3) logout
> >> (4) login
> >> (5) restarting the test
> >
> > well, there's setrlimit, so you could add a jackd client callback that
> > instructs all clients to change their RT_CPU_RATIO rlimit. In theory we
> > could try to add a new rlimit syscall that changes another task's rlimit
> > (right now the syscalls only allow the changing of the rlimit of the
> > current task) - that would enable utilities to change the rlimit of all
> > tasks in the system, achieving the equivalent of a global sysctl.
> Sure, we could. That does seem like an enormously complicated
> mechanism to accomplish something so simple. We are taking a global
> per-CPU limit, treating it as if it were per-process, then invoking a
> complex callback scheme to propagate new values, [...]

this was just a suggestion. It seems a remote-rlimit syscall is
possible, so there's no need to change Jack if you dont want to - that
syscall enables a utility that will change the rlimit for all running
tasks, so you'll get the 'simplicity of experimentation' of a global

(what you wont get is the ultra-fast time-to-market property of sysctl
hacks. I know that you'd probably prefer a global sysctl that you could
start using tomorrow, and i also know that the global sysctl would
suffice current Jackd needs, but we cannot sacrifice flexibility and
future utility for the sake of a couple of weeks/months of time

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.346 / U:3.420 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site