From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@ozlabs.org, mikey@neuling.org
Subject: Re: [V3] powerpc/irq: Enable some more exceptions in /proc/interrupts interface
Date: Wed, 12 Aug 2015 14:08:07 +0530 [thread overview]
Message-ID: <55CB05EF.5060900@linux.vnet.ibm.com> (raw)
In-Reply-To: <1439087233.3715.52.camel@kernel.crashing.org>
On 08/09/2015 07:57 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2015-08-04 at 19:57 +1000, Michael Ellerman wrote:
>> > On Mon, 2015-13-07 at 08:16:06 UTC, Anshuman Khandual wrote:
>>> > > This patch enables facility unavailable exceptions for generic facility,
>>> > > FPU, ALTIVEC and VSX in /proc/interrupts listing by incrementing their
>>> > > newly added IRQ statistical counters as and when these exceptions happen.
>>> > > This also adds couple of helper functions which will be called from within
>>> > > the interrupt handler context to update their statistics. Similarly this
>>> > > patch also enables alignment and program check exceptions as well.
>> >
>> > ...
>> >
>>> > > diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>>> > > index 0a0399c2..a86180c 100644
>>> > > --- a/arch/powerpc/kernel/exceptions-64s.S
>>> > > +++ b/arch/powerpc/kernel/exceptions-64s.S
>>> > > @@ -1158,6 +1158,7 @@ BEGIN_FTR_SECTION
>>> > > END_FTR_SECTION_IFSET(CPU_FTR_TM)
>>> > > #endif
>>> > > bl load_up_fpu
>>> > > + bl fpu_unav_exceptions_count
>> >
>> > Is it safe to call C code here?
> Even if it was (at some stage it wasn't, I'd have to look very closely
> to see what's the situation now), we certainly don't want to add
> overhead to load_up_fpu.
As I had already mentioned in the V2 thread of this patch, the
FPU performance with this patch being applied is still very much
comparable to the kernel without this patch. Though I have not
verified whether this still holds true with the new changes being
proposed in exceptions-64s.S (earlier reply in this thread) to
make the C function call safer.
Average of 1000 iterations (context_switch2 --fp 0 0)
With the patch : 322599.57 (Average of 1000 results)
Without the patch : 320464.924 (Average of 1000 results)
With standard deviation of the results.
6029.1407073288 (with patch ) 5941.7684079774 (without patch)
Wondering if the result above still does not convince us
that FPU performance might not be getting hit because of
this patch, let me know if we need to do more experiments.
prev parent reply other threads:[~2015-08-12 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 8:16 [PATCH V3] powerpc/irq: Enable some more exceptions in /proc/interrupts interface Anshuman Khandual
2015-07-21 8:13 ` Anshuman Khandual
2015-08-04 9:57 ` [V3] " Michael Ellerman
2015-08-06 13:24 ` Anshuman Khandual
2015-08-14 2:52 ` Michael Ellerman
2015-08-19 13:54 ` Anshuman Khandual
2015-08-09 2:27 ` Benjamin Herrenschmidt
2015-08-12 8:38 ` Anshuman Khandual [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=55CB05EF.5060900@linux.vnet.ibm.com \
--to=khandual@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=mpe@ellerman.id.au \
/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).