Re: [PATCH] parisc: Improve initial IRQ to CPU assignment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/5/19 4:21 PM, Helge Deller wrote:
On 05.01.19 00:21, Dennis Clarke wrote:
On 1/4/19 6:05 PM, Helge Deller wrote:
On parisc, each IRQ can only be handled by one CPU, and currently CPU0
is choosen as default for handling all IRQs by default.
With this patch we now assign each requested IRQ to one of the online
CPUs (and thus distribute the IRQs across all CPUs), even without an
instance of irqbalance running.

Will this take into consideration the features in default_smp_affinity
and allow processor cores to be considered 'non interrupt' service
state?

It seems the feature of default_smp_affinity to disable specific cores from
servicing interrupts doesn't work on the parisc platform.
On a 2-CPU machine I booted with the "irqaffinity=0" kernel commandline option
(to enable CPU#0 and disable CPU#1), which then led to a hanging kernel when
CPU#1 ist started.
On parisc, each CPU needs to handle at least it's timer and IPMI interrupt.
Any idea what I should try?

Sorry, the first question was "does this work there" and we now know it
is most likely "no". I tried similar on ppc64 and also arrived at
nothing but problems.

I am somewhat focused on digging into RISC-V at the moment and your post
raised the question in my mind.

One of the features I once enjoyed about Solaris was that it could
easily bring cpu cores online and offline as well as disable irq service
disruptions on any core with a trivial one line command. I always wanted
to port something similar over to linux but would start with something
interesting like RISC-V.

I'll get back to you on this one.

Dennis Clarke

ps: Also I still have those black superdomes standing around doing
    nothing and still want to get serial attached, powered up, etc.
    Yet another news years resolution post-it note idea.











[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux