![]() | |||||||||||||
Messages in this thread |
On Tue, May 08, 2007 at 12:29:19PM +0900, Satoru Takeuchi wrote: > > We used to be able to create kernel threads higher than any userspace > > priority. If this is no longer true, I think that's OK: equal priority > > still means we'll get scheduled, right? > > IF SCHED_RR, yes. However, if SCHED_FIFO, no. Such process doen't have timeslice > and only relinquish CPU time voluntarily. yeah ..this is truly a problem if SCHED_FIFO user-space cpu hog task is running at MAX_USER_RT_PRIO (which happens to be same as max real-time priority kernel threads can attain - MAX_RT_PRIO). One option is to make MAX_USER_RT_PRIO < MAX_RT_PRIO. I am not sure what semantics that will break (perhaps the real-time folks can clarify that). The other easier option is to add a wake_up_process_to_front() API in sched.c, which essentially wakes up the process and enqueues the task to the front of runqueue. > # Hence this problem is complicated ;-( -- Regards, vatsa - 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: 2007-05-08 04:05 [from the cache] ©2003-2008 | |||||||||||||