On 4/25/07, Raseel Bhagat <raseelbhagat@xxxxxxxxx> wrote:
Thanks,
According to both replies i think i miss explain my goal. To set that goal clear,I'm not interested in giving priority to some interrupt other than the other, all is i want is to let that CPU intensive process work on one processor without being much interrupted with hardware interrupts that will be routed to the other processor
If doing so will help the user-level process to live and work more efficient then what is the impact of routing all the interrupts to one processor to let the other CPU free for my CPU hungry user-level process live as much as possible less interrupted.
I hope it's clear not, but anyway let me ask another question, does the interrupt distribution algorithm takes a user-level process running on the processor into accounts in its decision of interrupt distribution?
more clear, what are the parameters taken into consideration when Linux wants to decide which processor will handle this incoming interrupt
Thank previously
Hi
On 4/25/07, Muhammad Tayseer Alquoatli <idoit.ief@xxxxxxxxx> wrote:
> Hi all:
> I'm wondering about interrupts distribution in Linux kernel, lets say
> i'm running Linux on a dual core processor, then Linux will distribute
> incoming interrupts between these two cores (processors)
> lets say also i'm running a service that uses nearly equal
> cpu/io/network time like a proxy that has many things to check in the
> content before issue an IO command to HDs or to network interface
> the question is, is it better to let all IO/network interrupts be
> routed to CPU0 and assign CPU1 to run the service user-level process ?
> or let Linux handles it if Linux can do it more efficiently
Usually its a good idea to let Linux do it.
> and what is the side effect of such partitioning on high IO/network
> interrupts on CPU0?
> In general, is manual interrupt/cpu assignment on SMP machine a good
> or a bad idea?
> Thanks in advance
There is an RTOS (RTLinux) whose basic idea is to let the Linux
kernel handle all non-RT events while another mini-kernel sitting on
top of the vanilla kernel, handles all real time tasks.
So, if such a bifurcation can be handled at the software level to give
"hard" real time performance, it would certainly be very interesting
to do so at the hardware level as well.
Thanks,
According to both replies i think i miss explain my goal. To set that goal clear,I'm not interested in giving priority to some interrupt other than the other, all is i want is to let that CPU intensive process work on one processor without being much interrupted with hardware interrupts that will be routed to the other processor
If doing so will help the user-level process to live and work more efficient then what is the impact of routing all the interrupts to one processor to let the other CPU free for my CPU hungry user-level process live as much as possible less interrupted.
I hope it's clear not, but anyway let me ask another question, does the interrupt distribution algorithm takes a user-level process running on the processor into accounts in its decision of interrupt distribution?
more clear, what are the parameters taken into consideration when Linux wants to decide which processor will handle this incoming interrupt
Thank previously
--
Muhammad Tayseer Alquoatli
