lkml.org 
[lkml]   [2009]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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.

Chris


\
 
 \ /
  Last update: 2009-05-12 19:03    [W:1.138 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site