CPU pinning

[Peter Teoh]

On Fri, Sep 16, 2011 at 5:08 AM, Kernel Piddu <kernelpiddu at gmail.com> wrote:
>
> > I have a multi processor system/machine and I would like dedicate a CPU entirely to listen on to a port.
> > I would greatly appreciate if you could tell me how this can be done.
> >
> > Thanks!
>

doing this in the kernel, is perhaps not really recommended, and linux
kernel is become UNIX-non-compliant if such features were ever
provided.
but userspace, is definitely possible, but is always a suggestive
tuning....the kernel can always override your request:
http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html
but this is per-process, if u want per-port IRQ handling attach to the
core, then this is going to affect the algorithm kernel used for
SoftIRQ handling:

doing a "cat /proc/softirqs" on my system:

                CPU0       CPU1       CPU2       CPU3
      HI:          0          0          0          0
   TIMER:     563854     591025          0          0
  NET_TX:          7          6          0          0
  NET_RX:      17486      19250          0          0
   BLOCK:      28888       3784          0          0
BLOCK_IOPOLL:          0          0          0          0
 TASKLET:     399230     391008          0          0
   SCHED:     116858     119604          0          0
 HRTIMER:        978        610          0          0
     RCU:     158513     192567          0          0

i can see that the IRQ processing is skewed, but then unless i have an
overall picture of what every core is doing.....not advisable to touch
that.

anyway looking at the "processes":

root         3     2  0 16:59 ?        00:00:00 [ksoftirqd/0]
root         7     2  0 16:59 ?        00:00:00 [ksoftirqd/1]

only two tasklet thread are spawned to handle the these softirq at
each core.   i suspect some error in the interpreting the number of
cores here, as there is only two core. (/proc/cpuinfo).

good reading on these internals:

http://lwn.net/Articles/308117/
http://www.wil.cx/matthew/lca2003/paper.pdf

--
Regards,
Peter Teoh