lkml.org 
[lkml]   [2006]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Where is RLIMIT_RT_CPU?
    From
    Date
    > Who said suid root? What about suid realtime or suid audio?

    Still, I don't see what you gain by making them setuid $group vs
    allowing member(s) of $group to use rt scheduling.

    > My point is not that they can lock up the machine. My point is that you
    > just can't add a rt task to a rt system! A rt-system consists of a fixed
    > set of threads, which in worst case can meet it's deadlines. If you add
    > just one task you might break the whole system. Only someone with overview
    > of the whole system can add those tasks.

    This issue can also happen if you start 10 suid rt apps. It's the
    responsibility of the user to make sure there's no bad interaction. The
    reason we want a limit is to make sure the system remains relatively
    responsive (not just up). In the ideal case (not sure it's possible),
    the scheduler would make sure that non-root rt apps wouldn't get (on
    average) more CPU than they would get running at normal priority. i.e.
    if there are 3 tasks competing and you start a rt task, then that task
    couldn't get more than 25% CPU. Of course, it may not be possible to do
    that perfectly, but anything remotely close would be pretty good.

    In any case, most audio (and probably other) applications tend to only
    require a very small amount (<10%) of CPU to run properly. I'd be quite
    happy is my system was configured to allow me to run rt tasks as long as
    the total doesn't exceed 30% CPU.

    > It is very simple if you have only a audio application or only a driver
    > needing low latencies. What if you have both? You have to make sure that
    > the higher priority one leaves enough cpu for the lower priority one. And
    > it is not a question of using a low percentage of cpu. It is a question of
    > how long the cpu is used in one go and how often it can happen within the
    > critical timeframe of the lower priority application.

    I understand that, but adding artificial restrictions (to setuid audio
    apps) isn't going to help.

    > You can make a system which checks that but it is much harder to do than
    > a moving average. The only thing which makes sense is (a) square filter(s)
    > with a width equal to the required latency of the lower priority task(s).

    Why not? It could be nice as well if someone wants to implement that.
    I'd already be quite happy to just have basic control on the CPU time.

    > So the sys-admin should somehow be able to give the right either to
    > specific (audio) applications with specific priorities or a developer whom
    > he trusts (and it does not make sense to give it to both as they would
    > then mess it up for each other!)

    How about simply giving rt rights to whomever is logged on the console?
    That's the user that really counts since he's (usually) next to the
    audio device.

    > We have discussed that total lock-up can be prevented with a simple
    > watchdog. That solution doesn't need anything added into the scheduler.

    As I mentioned earlier, it's not about total lock-up, but having things
    run relatively smoothly and (if possible?) even fairly.

    Jean-Marc
    -
    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/

    \
     
     \ /
      Last update: 2006-07-17 13:55    [W:3.888 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site