Hello,
Is it possible to determine if _native_ isel is available from userspace
somehow? So far my searches on the web and within kernel (headers)/glibc
were fruitless (aux vectors, cpu_user_features), few people people (Hollis
Blanchard, Richard Henderson) suggested PPC_FEATURE_ARCH_2_06, but
PowerISA_V2.06B_V2_PUBLIC.pdf says - "3.3.11 Fixed-Point Select [Category:
Phased-In (sV2.06)]" about isel, the sV2.06 (s part) means something i
suppose, furthermore Hollis mentioned that some pre 2.06 cores came with
isel.
Thanks.
--
mailto:av1474@comtv.ru
From: Gabriel Paubert <hidden> Date: 2012-09-22 11:28:40
On Sat, Sep 22, 2012 at 02:12:42PM +0400, malc wrote:
On Sat, 22 Sep 2012, Segher Boessenkool wrote:
quoted
quoted
Is it possible to determine if _native_ isel is available from userspace
somehow?
Just try to execute one and catch the SIGILL?
Unfortunately my kernel emulates ISEL for me in this case, so i don't
get any SIGILLs.
Perform a few isels in a loop between a couple of mftb and measure the
shortest time it takes. Any emulation will take tens of timebase ticks,
hardware implementation will return very small values, perhaps even
0 depending on the relationship between core and timebase frequencies.
I don't remember whether it's necessary inserting an isync between the
two mftb. I believe that even on the most OOO machines, two mftb in
a row will not be reordered to the point that the second executes before
the first.
Gabriel
On Sat, Sep 22, 2012 at 02:12:42PM +0400, malc wrote:
quoted
On Sat, 22 Sep 2012, Segher Boessenkool wrote:
quoted
quoted
Is it possible to determine if _native_ isel is available from userspace
somehow?
Just try to execute one and catch the SIGILL?
Unfortunately my kernel emulates ISEL for me in this case, so i don't
get any SIGILLs.
Perform a few isels in a loop between a couple of mftb and measure the
shortest time it takes. Any emulation will take tens of timebase ticks,
hardware implementation will return very small values, perhaps even
0 depending on the relationship between core and timebase frequencies.
I don't remember whether it's necessary inserting an isync between the
two mftb. I believe that even on the most OOO machines, two mftb in
a row will not be reordered to the point that the second executes before
the first.
Thanks for suggestion, but i'd rather not play with heuristics.
--
mailto:av1474@comtv.ru
From: David Gibson <hidden> Date: 2012-09-22 16:13:31
On Sat, Sep 22, 2012 at 07:37:03PM +0400, malc wrote:
On Sat, 22 Sep 2012, Gabriel Paubert wrote:
quoted
On Sat, Sep 22, 2012 at 02:12:42PM +0400, malc wrote:
quoted
On Sat, 22 Sep 2012, Segher Boessenkool wrote:
quoted
quoted
Is it possible to determine if _native_ isel is available from userspace
somehow?
Just try to execute one and catch the SIGILL?
Unfortunately my kernel emulates ISEL for me in this case, so i don't
get any SIGILLs.
Perform a few isels in a loop between a couple of mftb and measure the
shortest time it takes. Any emulation will take tens of timebase ticks,
hardware implementation will return very small values, perhaps even
0 depending on the relationship between core and timebase frequencies.
I don't remember whether it's necessary inserting an isync between the
two mftb. I believe that even on the most OOO machines, two mftb in
a row will not be reordered to the point that the second executes before
the first.
Thanks for suggestion, but i'd rather not play with heuristics.
It sounds like the sort of thing that ought to be in the ELF aux
vector, but I don't know if it actually is.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-09-22 19:55:50
On Sat, 2012-09-22 at 21:08 +0200, Segher Boessenkool wrote:
quoted
Thanks for suggestion, but i'd rather not play with heuristics.
Have a look at /sys/kernel/debug/powerpc/emulated_instructions/ then?
Userspace should *NEVER* rely on the content of debugfs, it will change
with time, it is not a guaranteed ABI, it's purely for people to look
at... for debugging.
Unfortunately we don't expose ISEL support via features (maybe we
should, this is reasonably easy to fix, except that we are running short
on feature bits and adding a new set of bits isn't totally trivial).
At this stage I would recommend using arch 2.06 as your key/trigger and
either add a handful of known PVR values (mfpvr is emulated) for other
CPUs you know support it (there shouldn't be that many), or just do the
heuristic :-(
Cheers,
Ben.
On Sun, 23 Sep 2012, Benjamin Herrenschmidt wrote:
On Sat, 2012-09-22 at 21:08 +0200, Segher Boessenkool wrote:
quoted
quoted
Thanks for suggestion, but i'd rather not play with heuristics.
Have a look at /sys/kernel/debug/powerpc/emulated_instructions/ then?
Userspace should *NEVER* rely on the content of debugfs, it will change
with time, it is not a guaranteed ABI, it's purely for people to look
at... for debugging.
Furthermore this box simply doesn't have it built-in...
Unfortunately we don't expose ISEL support via features (maybe we
should, this is reasonably easy to fix, except that we are running short
on feature bits and adding a new set of bits isn't totally trivial).
At this stage I would recommend using arch 2.06 as your key/trigger and
either add a handful of known PVR values (mfpvr is emulated) for other
CPUs you know support it (there shouldn't be that many), or just do the
heuristic :-(
Have a look at /sys/kernel/debug/powerpc/emulated_instructions/ then?
Userspace should *NEVER* rely on the content of debugfs, it will
change
with time, it is not a guaranteed ABI, it's purely for people to look
at... for debugging.
malc didn't say what he wants it for... People are in userspace as
well ;-)
At this stage I would recommend using arch 2.06 as your key/trigger
and
either add a handful of known PVR values (mfpvr is emulated) for other
CPUs you know support it (there shouldn't be that many), or just do
the
heuristic :-(
That's for 64-bit; another good option for 64-bit is to just never use
isel, it hardly ever buys you anything. It is much more useful on the
(older) 32-bit cores that support it.
Why does the kernel emulate this, btw? I can see emulation is useful
for running older binaries, for instructions that have been removed
from the architecture; but for newly added instructions, or optional
instructions, it hurts more than it helps?
Segher
From: Gabriel Paubert <hidden> Date: 2012-09-24 07:56:08
On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
Why does the kernel emulate this, btw? I can see emulation is useful
for running older binaries, for instructions that have been removed
from the architecture; but for newly added instructions, or optional
instructions, it hurts more than it helps?
Indeed. I also don't understand why mfpvr is emulated. That's the kind
of information that should be passed to the executables through auxiliary
vectors. After all, you can (or could at least) compile a kernel without
Altivec support and run it on a processor with Altivec.
Therefore, whether Altivec is supported or not, is a matter of
processor and kernel options. Provide this information through
the auxiliary vector and the problem is solved.
Gabriel
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-09-24 07:58:58
On Mon, 2012-09-24 at 09:55 +0200, Gabriel Paubert wrote:
On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
quoted
Why does the kernel emulate this, btw? I can see emulation is useful
for running older binaries, for instructions that have been removed
from the architecture; but for newly added instructions, or optional
instructions, it hurts more than it helps?
Indeed. I also don't understand why mfpvr is emulated. That's the kind
of information that should be passed to the executables through auxiliary
vectors. After all, you can (or could at least) compile a kernel without
Altivec support and run it on a processor with Altivec.
Therefore, whether Altivec is supported or not, is a matter of
processor and kernel options. Provide this information through
the auxiliary vector and the problem is solved.
Which we do. mfpvr is available as a fallback (essentially because if we
don't do it somebody's going to parse /proc/cpuinfo which is arguably
worse :-)
We should definitely advertise the availability of isel.
Cheers,
Ben.
From: Gabriel Paubert <hidden> Date: 2012-09-24 08:06:40
On Mon, Sep 24, 2012 at 05:58:37PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-09-24 at 09:55 +0200, Gabriel Paubert wrote:
quoted
On Sun, Sep 23, 2012 at 03:46:06AM +0200, Segher Boessenkool wrote:
quoted
Why does the kernel emulate this, btw? I can see emulation is useful
for running older binaries, for instructions that have been removed
from the architecture; but for newly added instructions, or optional
instructions, it hurts more than it helps?
Indeed. I also don't understand why mfpvr is emulated. That's the kind
of information that should be passed to the executables through auxiliary
vectors. After all, you can (or could at least) compile a kernel without
Altivec support and run it on a processor with Altivec.
Therefore, whether Altivec is supported or not, is a matter of
processor and kernel options. Provide this information through
the auxiliary vector and the problem is solved.
Which we do. mfpvr is available as a fallback (essentially because if we
don't do it somebody's going to parse /proc/cpuinfo which is arguably
worse :-)
Fine. But I believe that mfpvr emulation came first, which is the point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
Bottom line, the mappin between PVR and capabilities offered to
applications should happen in one place, and this place is the kernel.
We should definitely advertise the availability of isel.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-09-24 09:42:13
On Mon, 2012-09-24 at 10:06 +0200, Gabriel Paubert wrote:
quoted
Which we do. mfpvr is available as a fallback (essentially because if we
don't do it somebody's going to parse /proc/cpuinfo which is arguably
worse :-)
Fine. But I believe that mfpvr emulation came first, which is the point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
Heh, possibly, I don't remember... I added the cputable, I think we
added mfpvr because we didn't have anything, then I added cputable which
got us the HW caps, but some old stuff still relied on mfpvr so we
couldn't completely remove it.
Bottom line, the mappin between PVR and capabilities offered to
applications should happen in one place, and this place is the kernel.
Yes, we all agree here.
quoted
We should definitely advertise the availability of isel.
Agreed.
If somebody has 5mn, patch welcome :-)
Cheers,
Ben.
From: Scott Wood <hidden> Date: 2012-09-24 23:55:23
On 09/22/2012 08:46:06 PM, Segher Boessenkool wrote:
quoted
quoted
Have a look at /sys/kernel/debug/powerpc/emulated_instructions/ =20
then?
=20
Userspace should *NEVER* rely on the content of debugfs, it will =20
change
with time, it is not a guaranteed ABI, it's purely for people to look
at... for debugging.
=20
malc didn't say what he wants it for... People are in userspace as
well ;-)
=20
quoted
At this stage I would recommend using arch 2.06 as your key/trigger =20
and
either add a handful of known PVR values (mfpvr is emulated) for =20
other
CPUs you know support it (there shouldn't be that many), or just do =20
the
heuristic :-(
The ISA says that isel is "Category: Phased-In (sV2.06)" -- are there =20
any 2.06 chips that don't have it?
That's for 64-bit; another good option for 64-bit is to just never use
isel, it hardly ever buys you anything. It is much more useful on the
(older) 32-bit cores that support it.
Why is it more useful on 32-bit? If you're referring to the =20
performance of specific cores rather than some architectural thing, =20
maybe that's true with some chips, but on the Freescale side I'd be =20
surprised if e5500 were much different from e500v2 in that regard.
-Scott=
From: Scott Wood <hidden> Date: 2012-09-25 00:41:00
On 09/24/2012 07:32:03 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
quoted
The ISA says that isel is "Category: Phased-In (sV2.06)" -- are =20
there
quoted
any 2.06 chips that don't have it?
=20
I believe "malc" is interested in knowing about pre-2.06 chips that =20
have
it.
You said to key off of 2.06 plus a PVR whitelist for pre-2.06 chips =20
that have it. Wouldn't you also need a PVR blacklist for 2.06 chips =20
that don't have it (unless there are no such things)? Or if one is =20
only interested in pre-2.06 chips, why check for 2.06 at all?
-Scott=
From: Scott Wood <hidden> Date: 2012-09-25 00:51:02
On 09/24/2012 07:47:28 PM, malc wrote:
On Tue, 25 Sep 2012, Benjamin Herrenschmidt wrote:
=20
quoted
On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
quoted
The ISA says that isel is "Category: Phased-In (sV2.06)" -- are =20
there
quoted
quoted
any 2.06 chips that don't have it?
I believe "malc" is interested in knowing about pre-2.06 chips that =20
have
quoted
it.
=20
That too, but also what 's' prefix means.
I think it's trying to say that it's phased-in for server but mandatory =20
for embedded, though I don't see that exact notation used anywhere else =20
in the document.
-Scott=
Fine. But I believe that mfpvr emulation came first, which is the
point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
Heh, possibly, I don't remember... I added the cputable, I think we
added mfpvr because we didn't have anything, then I added cputable
which
got us the HW caps, but some old stuff still relied on mfpvr so we
couldn't completely remove it.
If I have my history right end up, MFPVR emulation was added for MoL.
Which is funny (if you like that kind of thing) because it now hurts
all other "hypervisor in userspace" kind of things, that might want
to lie in their emulated PVR...
Segher
That's for 64-bit; another good option for 64-bit is to just never
use
isel, it hardly ever buys you anything. It is much more useful on
the
(older) 32-bit cores that support it.
Why is it more useful on 32-bit? If you're referring to the
performance of specific cores rather than some architectural thing,
maybe that's true with some chips, but on the Freescale side I'd be
surprised if e5500 were much different from e500v2 in that regard.
Yes, I was talking about the older cores. I'd be surprised if ISEL is
often a win on e5500, but I don't really know. I forgot about that chip
to tell you the truth :-)
Segher
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-09-25 20:59:55
On Tue, 2012-09-25 at 15:17 +0200, Segher Boessenkool wrote:
quoted
quoted
Fine. But I believe that mfpvr emulation came first, which is the
point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
Heh, possibly, I don't remember... I added the cputable, I think we
added mfpvr because we didn't have anything, then I added cputable
which
got us the HW caps, but some old stuff still relied on mfpvr so we
couldn't completely remove it.
If I have my history right end up, MFPVR emulation was added for MoL.
Which is funny (if you like that kind of thing) because it now hurts
all other "hypervisor in userspace" kind of things, that might want
to lie in their emulated PVR...
Are you sure ? MOL had a kernel module, it wouldn't have needed that...
Cheers,
Ben.
From: Kumar Gala <hidden> Date: 2012-09-26 00:18:00
On Sep 25, 2012, at 3:59 PM, Benjamin Herrenschmidt wrote:
On Tue, 2012-09-25 at 15:17 +0200, Segher Boessenkool wrote:
quoted
quoted
quoted
Fine. But I believe that mfpvr emulation came first, which is the =20=
quoted
quoted
quoted
point
I object to (see the mess that the fact that CPUID is available to
applications made to x86 when SSE registers were added).
=20
Heh, possibly, I don't remember... I added the cputable, I think we
added mfpvr because we didn't have anything, then I added cputable =20=
quoted
quoted
which
got us the HW caps, but some old stuff still relied on mfpvr so we
couldn't completely remove it.
=20
If I have my history right end up, MFPVR emulation was added for MoL.
Which is funny (if you like that kind of thing) because it now hurts
all other "hypervisor in userspace" kind of things, that might want
to lie in their emulated PVR...
=20
Are you sure ? MOL had a kernel module, it wouldn't have needed =
that...
I feel like there was some JVMs (IBMs?) that used MFPVR to determine =
some things.
- k=