From: Dennis Clarke <dclarke@blastwave.org>
To: Helge Deller <deller@gmx.de>,
linux-parisc@vger.kernel.org,
James Bottomley <James.Bottomley@HansenPartnership.com>,
John David Anglin <dave.anglin@bell.net>
Subject: Re: [PATCH] parisc: Improve initial IRQ to CPU assignment
Date: Sat, 5 Jan 2019 16:45:19 -0500 [thread overview]
Message-ID: <0d94b184-fd9f-b143-037f-7536f9e59625@blastwave.org> (raw)
In-Reply-To: <e3ba658f-9505-8258-8172-746e234a8bb4@gmx.de>
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.
next prev parent reply other threads:[~2019-01-05 21:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-04 23:05 [PATCH] parisc: Improve initial IRQ to CPU assignment Helge Deller
2019-01-04 23:21 ` Dennis Clarke
2019-01-05 21:21 ` Helge Deller
2019-01-05 21:45 ` Dennis Clarke [this message]
2019-01-05 22:36 ` Helge Deller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d94b184-fd9f-b143-037f-7536f9e59625@blastwave.org \
--to=dclarke@blastwave.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dave.anglin@bell.net \
--cc=deller@gmx.de \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).