> > Hmmm... Are you suggesting it is OK for a kernel to get nearly completely > > hosed and for not fully utilize all the processors in the system because > > of one SCHED_FIFO thread? > > Sure. You specifically directed the scheduler to run your thread at a > higher priority than anything else. The way I see it, you used root's > perogative to shoot himself in the foot. You could also have used root's > perogative to don steel toed shoes(set important kernel threads to a higher > priority) before pulling the trigger.
No, I specifically directed the scheduler to run my thread at a higher priority than any other userspace application. The fact that I wrote it in userspace and not in kernel space implies that I am OK with the kernel stopping me sometimes when _it_ has work to do. If I wanted something higher priority than the kernel I would have written something in kernel space instead. > SCHED_FIFO thread are supposed to preempt > > all other userspace threads... not the kernel itself. > > Not so. The scheduler makes do distinction between user and kernel threads > of execution. That is SOOOO broken it isn't even funny. > If you think that's broken, you'll _love_ Ingo's IRQ threads. While testing > one of his recent (slightly buggy)unpriveleged-user-does-RT patches in an > IRQ threadified kernel, I ran a user SCHED_FIFO task at higher than the IRQ0 > thread... if my box had been an embeded washing machine controller instead > of a desktop box, it'd have been a classic case of "No tickie no washie" :)) Yeah, thats broken too. Perhaps I don't understand this philosophy you have where the kernel isn't more important than everything else. It seems to me like there needs to be a rigid hierarchy for scheduling, lest you get into deadlock problems: 1. Kernel preempts all. There may be some hierarchy of kernel priorities too, but it isn't important here. 2. SCHED_FIFO processes preempt all userspace applications. 3. SCHED_RR. 4. SCHED_OTHER. Under no circumstances should any single CPU-bound userspace thread completely hose a 64-way SMP box. Can somebody educate me on why it is correct to do it any other way? Chad - 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/
