[lkml]   [2009]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] Multimedia scheduling class, take 2
    Jussi Laako wrote:
    > Chris Friesen wrote:
    >>If all you're trying to do is allow different threads to run at
    >>different nice levels, what about extending sys_setpriority() to take a
    >>"which" of PRIO_THREAD? We'd probably have to call the syscall directly
    >>until/unless libc picks up the new option.
    > How would this be mapped to a POSIX standard API?

    You'd call sys_setpriority. Actually, you'd probably have to call
    syscall(__NR_getpriority...) until glibc picks up the new option.

    Then for the "which" field, instead of PRIO_PROCESS you would use a new
    PRIO_THREAD (or PRIO_TASK, whichever makes more sense) which would only
    set the nice level for the specific thread specified in the "who" field.

    Of course, without glibc/pthreads support you would only be able to set
    the nice level for the current thread since you don't have any way to
    map from "pthread_t *" to tid. And you wouldn't be able to create new
    threads with a particular nice level already set. But that argument
    holds true for a new sched policy as well, because glibc checks the
    policy internally and only knows about the normal three.

    > I would like to see
    > something which works straight out with
    > pthread_setschedprio()/pthread_getschedparam(). In order it to work
    > correctly it also needs sys_sched_get_priority_min and
    > sys_sched_get_priority_max.

    This option extends the "nice" API rather than the static priority API,
    so all of the above would still have a static priority of 0 for SCHED_OTHER.


     \ /
      Last update: 2009-05-12 19:03    [W:0.021 / U:5.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site