Chris Friesen wrote: > Ingo Oeser wrote: > > Stupid applications can starve other applications for a while, but not > > forever, because the kernel is still running and deciding. > > Not so. > > > > task 1: sched_rr, priority 1, takes mutex > task 2: sched_rr, priority 2, cpu hog, infinite loop > task 3: sched_rr, priority 99, tries to get mutex > > And now tasks 1 and 3 are starved forever. Arguably bad application > design, but it demonstrates a case where applications can starve other > applications.
You are right. In "If a SCHED_RR process has been running for a time period equal to or longer than the time quantum, it will be put at the end of the list for its priority" I missed the "for its priority" part. You would need to change the priority of task 1 until it releases the mutex. Ideally the owner gets the maximum priority of his and all the waiters on it, until it releases his mutex, where he regains its old priority after release of mutex. But this priority elevation happens only, if he is runnable. If not, he gets his old priority back, until he is runnable. But then again you just need to grab a mutex shared with a high priority task and consume CPU. Since this behavior is not defined in POSIX AFAIK, you just have to write your applications properly or use SCHED_OTHER for CPU hogging. Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
