From: Thomas Gleixner <tglx@linutronix.de>
To: David Daney <ddaney.cavm@gmail.com>
Cc: Ioan Nicu <ioan.nicu.ext@nokia.com>,
Ralf Baechle <ralf@linux-mips.org>,
David Daney <david.daney@cavium.com>,
Aleksey Makarov <aleksey.makarov@auriga.com>,
Leonid Rosenboim <lrosenboim@caviumnetworks.com>,
Jiang Liu <jiang.liu@linux.intel.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Alexander Sverdlin <alexander.sverdlin@nokia.com>,
Uwe Duerr <uwe.duerr.ext@nokia.com>,
linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: Octeon: do not change affinity for disabled irqs
Date: Wed, 30 Mar 2016 10:48:19 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1603301030270.3978@nanos> (raw)
In-Reply-To: <56C3C9A4.1040109@gmail.com>
On Tue, 16 Feb 2016, David Daney wrote:
> On 02/15/2016 07:45 AM, Ioan Nicu wrote:
> > Octeon sets the default irq affinity to value 1 in the early arch init
> > code, so by default all irqs get registered with their affinity set to
> > core 0.
> >
> > When setting one CPU ofline, octeon_irq_cpu_offline_ciu() calls
> > irq_set_affinity_locked(), but this function sets the IRQD_AFFINITY_SET bit
> > in the irq descriptor. This has the side effect that if one irq is
> > requested later, after putting one CPU offline, the affinity of this irq
> > would not be the default anymore, but rather forced to "all cores - the
> > offline core".
> >
> > This patch sets the IRQCHIP_ONOFFLINE_ENABLED flag in octeon irq
> > controllers, so that the kernel would call the irq_cpu_[on|off]line()
> > callbacks only for enabled irqs. If some other irq is requested after
> > setting one cpu offline, it would use the default irq affinity, same as it
> > would do in the normal case where there is no CPU hotplug operation.
> >
> > Signed-off-by: Ioan Nicu <ioan.nicu.ext@nokia.com>
> > Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
>
> In principle, I don't object.
>
> I would like to see what tglx has to say about this though. If we are
> worried about the IRQD_AFFINITY_SET bit, I am not convinced that this is the
> best place to be tweaking code. Are we papering over something that should
> be handled in a more general manner? I don't know.
Hmm. Good question. We probably should not set IRQD_AFFINITY_SET when called
from the offline code. The flag was originally meant to preserve user space
affinity settings across request/free_irq.
Though it gets set via irq_set_affinity() as well and therefor via
irq_set_affinity_locked().
Now we could move that IRQD_AFFINITY_SET flip to the user space interface, but
we have to look at all the kernel internal call sites of irq_set_affinity()
and irq_set_affinity_locked() whether any of those relies on affinity settings
being preserved. irq_set_affinity_locked() probably not, as the only non core
user is the octeon code, but you probably can answer that question :)
Thanks,
tglx
prev parent reply other threads:[~2016-03-30 8:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 15:45 Ioan Nicu
2016-02-17 1:15 ` David Daney
2016-03-30 8:48 ` Thomas Gleixner [this message]
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=alpine.DEB.2.11.1603301030270.3978@nanos \
--to=tglx@linutronix.de \
--cc=aleksey.makarov@auriga.com \
--cc=alexander.sverdlin@nokia.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=ioan.nicu.ext@nokia.com \
--cc=jiang.liu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=lrosenboim@caviumnetworks.com \
--cc=marc.zyngier@arm.com \
--cc=ralf@linux-mips.org \
--cc=uwe.duerr.ext@nokia.com \
/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
all inboxes | Powered by JetHome®