| To: | Tim Wright <timw@xxxxxxxxx> |
|---|---|
| Subject: | Re: [Lse-tech] fwd: Process Pinning |
| From: | jamal <hadi@xxxxxxxxxx> |
| Date: | Sun, 24 Dec 2000 21:59:34 -0500 (EST) |
| Cc: | Andrew Morton <andrewm@xxxxxxxxxx>, Gerrit Huizenga <gerrit@xxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, Tim Hockin <thockin@xxxxxxxxxx>, <npollitt@xxxxxxx>, <lse-tech@xxxxxxxxxxxxxxxxxxxxx>, <slinx@xxxxxxxxxxxx>, <netdev@xxxxxxxxxxx> |
| In-reply-to: | <20001224124423.A1668@xxxxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-netdev@xxxxxxxxxxx |
On Sun, 24 Dec 2000, Tim Wright wrote: > The scheme is that you tell the APIC what your current priority is. The APIC > has a task priority register, but Linux doesn't use it. We just set it to > accept-all at boot time and leave it alone. If you use it to indicate your > current priority, the APIC bus will deliver the interrupt to the least-loaded > CPU. The RR behaviour (yes I'm a Brit :-) happens if there's a choice of > "least loaded". So it seems that the process is capable of setting a high enough priority such that an (hardware) interupt wont run on a specific CPU? My goal might be slightly different than this. I would like to route interupts to CPUs which have the "least load of interupts" in addition to process load. do you have a paper on this, maybe you can already do this? cheers, jamal |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | net link order, Keith Owens |
|---|---|
| Next by Date: | Re: [Lse-tech] fwd: Process Pinning, Tim Wright |
| Previous by Thread: | Re: [Lse-tech] fwd: Process Pinning, Tim Wright |
| Next by Thread: | Re: [Lse-tech] fwd: Process Pinning, Tim Wright |
| Indexes: | [Date] [Thread] [Top] [All Lists] |