From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: rsa@us.ibm.com
Cc: linuxppc-dev@ozlabs.org, Will Schmidt <will_schmidt@vnet.ibm.com>,
Steven Munroe <sjmunroe@us.ibm.com>
Subject: Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR
Date: Sat, 14 Mar 2009 14:22:18 +1100 [thread overview]
Message-ID: <1237000938.25062.74.camel@pasglop> (raw)
In-Reply-To: <1236997906.3346.8.camel@localhost.localdomain>
> Both of these thoughts came to mind. I don't have a particular
> preference. It's very likely that a process which results in the
> enabling of FP,VMX, or VSX may continue to use the facility for the
> duration of it's lifetime. Threads would be even more likely to exhibit
> this behavior.
>
> The case where this might not be true is if we use VMX or VSX for string
> routine optimization in GLIBC. This will require metrics to prove it's
> utility of course. Perhaps what I can do in the string routines is
> check if the bits are already set and use the facility if it is already
> enabled and the usage scenario warrants it, i.e. if the size and
> alignment of the data are in a sweet spot as indicated by profiling
> data.
Or we just add some instrumentation to today kernel to see how often
those gets enabled and then not-re-enabled on the next time slice and do
some stats with common workloads.
Ben.
next prev parent reply other threads:[~2009-03-14 3:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-13 20:23 [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR Ryan Arnold
2009-03-13 21:15 ` Kumar Gala
2009-03-13 22:45 ` Benjamin Herrenschmidt
2009-03-13 23:52 ` Josh Boyer
2009-03-14 2:31 ` Ryan Arnold
2009-03-14 3:22 ` Benjamin Herrenschmidt [this message]
2009-03-14 13:55 ` Segher Boessenkool
2009-03-14 13:49 ` Segher Boessenkool
2009-03-14 14:58 ` Ryan Arnold
2009-03-16 0:49 ` Benjamin Herrenschmidt
2009-03-16 6:43 ` Michael Neuling
2009-03-16 10:52 ` Gabriel Paubert
2009-03-14 8:20 ` Michael Neuling
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=1237000938.25062.74.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=rsa@us.ibm.com \
--cc=sjmunroe@us.ibm.com \
--cc=will_schmidt@vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.