On Wed, 2005-01-26 at 16:27 -0600, Jack O'Quin wrote: > 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 imagine users wanting to put in a safety limit even for > > root-owned RT tasks by making the rlimit 98% or so. Nonprivileged users > > would have this rlimit at say 20% in a typical desktop distribution. > > That seems rather small. CPU starvation is not generally much of a > problem on desktop machines. If that (single) user wants to eat up > 70% or 80% of the CPU, that's not likely to be a problem. Mac OS X > allows 90% on their desktop systems. >
Just a bit off the topic of this sub-thread... 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 situations. Secondly, I think we should agree upon and get the basic rlimit support in ASAP, so the userspace aspect can be firmed up a bit for people like Paul and Jack (this wouldn't preclude further work from happening in the scheduler afterwards). 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. Nick - 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://www.tux.org/lkml/
