RE: O(1) scheduler seems to lock up on sched_FIFO and sched_RR ta

[Perez-Gonzalez, Inaky]

> From: george anzinger [mailto:[e-mail]]
> Perez-Gonzalez, Inaky wrote:
> > ...
> > My point here is: I am trying to trace where this program
> > is making use of workqueues inside of the kernel, and I
> > can find none. ...<snip>...
> 
> Hm!  I wonder.  Robert is working on a fix for schedsetschedule()
> where it fails to actually tell the scheduler to switch to a process
> that it just made higher priority or away from one it just lowered.
> 
> The net result is that the caller keeps running (FIFO for all in this
> case) when, in fact it should have been switched out.  Next time
> schedule() actually switches, it is all sorted out again.  Could the
> elavation of the events/0 thread cause this needed switch?

Maybe it was that, as with Robert's patch, the hang goes
away ... gee, weirdo. Doing a brute-force grep of who is doing
anything that could wake up the event daemon (by calling
{queue,schedule}_[delayed_]work() or flush_{workqueue,delayed_work})
shows that arch/i386/kernel/cpu/mcheck:mce_timerfunc() is 
scheduling work every MCE_RATE seconds, so that could wake up
the event daemon and cause the thing to be sorted out. However,
that's each 15 seconds ... too slow?

The VT code does too (as a callback mechanism for setting the
console, and seems like scrolling), but none seems to be
periodic so that they'd fix it. Others are at too unclear too.

Oh well ... it works, so it goes to the bin :]

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)