[Top] [All Lists]

RE: [RFC] Adding the notion of System vs. Application processors

To: PianoMan <clemej@xxxxxxxxxxxx>
Subject: RE: [RFC] Adding the notion of System vs. Application processors
From: Dimitris Michailidis <dimitris@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 08 Aug 2000 13:57:08 -0700 (PDT)
Cc: linux-scalability@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.20.0008081604530.15916-100000@xxxxxxxxxxxxxxxxxxxx>
Organization: SGI
Sender: owner-LinuxScalability@xxxxxxxxxxx
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).

Tasklets probably.

>> 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
TLBs, etc.

> a SCHED_FIFO process doesn't get interrupted and switched out at a
> quanta???

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

<Prev in Thread] Current Thread [Next in Thread>