On 08-Aug-2000 PianoMan wrote:
> Now, either I'm being lied to by
> top (quite possible), or something is still getting scheduled on that
> processor.. I'm guessing bh's or softirq's (or system calls?) (since they
> don't use the "can_schedule" macro).
>> Don't turn off the timer interrupt. It would mess up time accounting. We
>> also need it for slab cache management. IPIs must also be left on.
> Excuse a novice kernel hacker, why would slab cache management be taking
> place on these processors? or is each processor marking the pages it uses
> with it's own timestamp..
When we need to shrink slab caches we ask each cpu to shrink its part
(caches are per-CPU these days). Then each CPU does it in its next timer
interrupt. We also need IPIs or we won't be able to send signals, flush
> a SCHED_FIFO process doesn't get interrupted and switched out at a
No, they keep executing until something higher priority comes along. Same
with SCHED_RR. When they run out of time they get a new quantum and continue
executing if they are the highest priority process around.
> you mean I could write a process now that does an infinate loop
> on a uniprocessor and it would block the whole machine?
Absolutely. That's why you need to be root to launch a real-time process.
> And I agree for the most part. but we need to add the bootup code the set
> the CPU mask, add the new pinning syscall, (arguably) make some minor
> modifications to the scheduler, and then look at softirq's and the like to
> see where these "other" artifacts I'm seeing are coming from. you are
> proposing doing I am proposing, essentially.
There are also a number of bugs that need to be fixed.
Dimitris Michailidis dimitris@xxxxxxxxxxxx