On Thu, Jan 17, 2013 at 02:35:58PM +0100, David Henningsson wrote: > In a discussion with JACK developer Paul Davis, he says: > > "at this point in time, i personally can see absolutely no reason > why a regular user should not have access to RT scheduling or > memlock if the kernel and PAM (or equivalent) are normally and > appropriately configured. give the user the ability to memlock 75% > of the system RAM, make sure that the RT scheduling parameters > reserve 5% of the CPU for non-RT tasks. done." > > The advantage of doing so is to remove one obstacle for having > low-latency audio working OOTB, without manual configuration.
This feels like a surprising amount of resources to grant to a user. On a single-user workstation, it would feel appropriate to allow the resources to be used as desired, but it wouldn't be appropriate for multiuser machines, shared-use systems, servers, etc. But for the few that really want a top-to-bottom realtime audio stack, adding a handful of /etc/security/limits.conf settings to change RLIMIT_RTPRIO and RLIMIT_MEMLOCK (I'm surprised it doesn't yet support RLIMIT_RTTIME, but without an explicit setting, probably sched_rt_runtime_us applies equally to all users) does not seem so bad: after all, those users also need to install and configure their software and hardware. 64K might seem like a remarkably low per-process locked memory limit, but it is per-process -- and on my 12.04 LTS laptop I'm allowed to create 125874 processes; the locked memory works out to nearly eight gigabytes in total, which feels like a lot. (Probably cgroups could enforce some reasonable per-user limits rather than just per-process limits.) A realtime priority of 0 also doesn't seem too surprising; those processes do win over non-realtime processes. Is two lines in a configuration file really so unreasonable? Thanks
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
