Messages in this thread | | | Date | Fri, 14 Jan 2005 12:55:12 -0800 | From | Matt Mackall <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
On Fri, Jan 14, 2005 at 12:10:21PM -0800, Chris Wright wrote: > * Matt Mackall (mpm@selenic.com) wrote: > > The closest thing to concensus I've seen yet was a new rlimit for > > scheduling with code from Chris Wright. The version I last saw had > > some rough edges on the API (exposing the internal scheduler priority > > levels) but wasn't too bad in principle. We really ought not get in > > the habit of adding new rlimits though. > > > > Perhaps he can post whatever he has again, I'm not sure what the > > current state is. > > This is the latest version, with the idea from Utz to break nice and > rtprio apart. > > The basic issue on the rlimit value is how to sanely encode nice values, > realtime prioroties and scheduler policies into a number. The first > incarnation was the clumsiest, and tried to pack it all into a number > in range of [0,139]. This, as many agree, too closely reflects kernel > internal values. This one gives 0-39 (nice values 19,-20) to RLIMIT_NICE, > and 0-99 (rt priorities) to RLIMIT_RTPRIO. There's no distinction in rt > policy, and the traditional override (CAP_SYS_NICE) is still in place. > The defaults for both rlimits are 0, and behaviour should be backwards > compatible. I tested this one a bit, and it worked as expected. I've > got a patch to pam_limits as well, although it's untested.
This is looking pretty good.
> +#define NICE_TO_RLIMIT_NICE(nice) (19 - nice) ... > +unsigned long nice_to_rlimit_nice(const int nice) > +{ > + return NICE_TO_RLIMIT_NICE(nice); > +}
This is a bit silly.
> - if (niceval < task_nice(p) && !capable(CAP_SYS_NICE)) { > + if (niceval < task_nice(p) && > + nice_to_rlimit_nice(niceval) > > + p->signal->rlim[RLIMIT_NICE].rlim_cur && > + !capable(CAP_SYS_NICE)) {
Perhaps we want another helper function to do the rlim and CAP_SYS_NICE check together.
-- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |