[lkml]   [2005]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM
    On Tue, 2005-01-11 at 13:28 -0800, Matt Mackall wrote:
    > On Tue, Jan 11, 2005 at 12:47:07PM -0800, Chris Wright wrote:
    > > Guys, could we please bring this back to a useful discussion. None of
    > > you have commented on whether the rlimits for priority are useful. As I
    > > said before, I've no real problem with the module as it stands since it's
    > > tiny, quite contained, and does something people need. But I agree it'd
    > > be better to find something that's workable as long term solution.
    > I almost like it. I don't like that it exposes the internal scheduler
    > priorities directly (-tiny in fact has options to change these!). So
    > perhaps some thought could be given to either stratifying it a bit
    > more (>2000 for SCHED_FIFO, >1000 for SCHED_RR, then SCHED_OTHER) or
    > separate limits for the different scheduling disciplines.
    > Right now, you can make a good argument that SCHED_FIFO > SCHED_RR >
    > SCHED_OTHER from a privilege point of view, but that could change if
    > we add a pseudo-RT scheduling class of some sort. Similarly, adding a
    > discipline means adding an rlimit with the split approach, so that's
    > not very friendly either.
    > Another way:
    > 0-20: normal nice values (inverted)
    > >20: privilege to set any RT priority
    > Limiting to below normal nice is a little weird and the offset to make
    > everything positive is weird as well. Above 20, any RT app can starve
    > SCHED_OTHER and it's less important to dole out fine-grained levels
    > here as these apps must be engineered to cooperate to some degree
    > anyway.

    Limiting to positive nice values are needed too. At leased i need such
    thing. Normal users are only allowed to increase the nice value (lower
    prio). If a user job runs at nice 15 they can't renice it to 5. I get
    about 3 calls a week to do this as root.

    And the presentation of the usual nice values can be done in userspace.
    pamlimits and ulimit already converts values (min -> s, KiB -> Bytes).

    And separating the nice and RT part is useful to prevent confusion in
    userspace tools and for the admin.

    I patched PAM which allows the setting of nice and realtime rlimits in

    nice goes from 19 to -20 (internally converted to 0-39).
    realtime from 0 - 99.

    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.024 / U:2.628 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site