2016-05-05 4:51 GMT+08:00 Grochowalski, Matthew (GE Aviation, US) <matthews.grochowal...@ge.com>: > It looks like commit 81a44c5 (sched: Queue RT tasks to head when prio drop) > made the behavior on dropping (userspace view) more sensible but I believe > the behavior is still incorrect according to POSIX. > > POSIX (in volume 2 section 2.8.4 Process Scheduling) specifies two different > semantics for where the task is placed in the thread list for the new priority > > 8. If a thread whose policy or priority has been modified by > pthread_setschedprio() is a running thread or is runnable, the effect on its > position in the thread list depends on the direction of the modification, as > follows: > a. If the priority is raised, the thread becomes the tail of the > thread list. > b. If the priority is unchanged, the thread does not change position > in the thread list. > c. If the priority is lowered, the thread becomes the head of the > thread list. > 7. If a thread whose policy or priority has been modified other than by > pthread_setschedprio() is a running thread or is runnable, it then becomes > the tail of the thread list for its new priority. > > Commit 81a44c5 made all of the priority change functions behave according to > the pthread_setschedprio semantics. > > It appears commit ff77e46 (sched/rt: Fix PI handling vs. > sched_setscheduler()) causes changing a task's priority to its existing > priority to requeue it at the tail.
So this is almost follow 7, right? > So a task settings its own priority to its current priority would be the same > as a sched_yield(). > > I believe the correct behavior is to have the existing priority change > syscalls (sched_setscheduler and sched_setparam) always move the changed task > to the back of the queue for the new priority. > > But as far as I can tell the kernel provides no way to implement > pthread_setschedprio with the correct semantics. > > It seems the best way to implement this would be adding a flag > (SCHED_SETSCHEDPRIO) to the existing sched_setattr syscall. > > Any thoughts? > > Thanks, > --Matt Grochowalski > > -- Regards, Wanpeng Li
