From: Ryan Arnold <rsa@us.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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: Fri, 13 Mar 2009 21:31:46 -0500 [thread overview]
Message-ID: <1236997906.3346.8.camel@localhost.localdomain> (raw)
In-Reply-To: <1236984351.25062.71.camel@pasglop>
On Sat, 2009-03-14 at 09:45 +1100, Benjamin Herrenschmidt wrote:
> > If these applications are aware they are heavy users (of FP, VMX, VSX)
> > can we not use a sysctl()? Doing so wouldn't be that difficult.
> >
> > I think trying to do something based on a runtime heuristic sounds a
> > bit iffy.
>
> Another option might be simply to say that if an app has used FP, VMX or
> VSX -once-, then it's likely to do it again and just keep re-enabling
> it :-)
>
> I'm serious here, do we know that many cases where these things are used
> seldomly once in a while ?
>
> An if we do, maybe then a simple counter in the task struct... if the
> app re-enables it more than a few consecutive switches, then make it
> stick. I have the feeling that would work out reasonably well.
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.
Regards,
Ryan
next prev parent reply other threads:[~2009-03-14 2:32 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 [this message]
2009-03-14 3:22 ` Benjamin Herrenschmidt
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=1236997906.3346.8.camel@localhost.localdomain \
--to=rsa@us.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--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 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).