Probing for native availability of isel from userspace

Probing for native availability of isel from userspace

[malc]

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

Re: Probing for native availability of isel from userspace

[Segher Boessenkool]

> Is it possible to determine if _native_ isel is available from  
> userspace
> somehow?

Just try to execute one and catch the SIGILL?


Segher

Re: Probing for native availability of isel from userspace

[malc]

On Sat, 22 Sep 2012, Segher Boessenkool wrote:

> > 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.

-- 
mailto:av1474@comtv.ru

Re: Probing for native availability of isel from userspace

[Gabriel Paubert]

On Sat, Sep 22, 2012 at 02:12:42PM +0400, malc wrote:
> On Sat, 22 Sep 2012, Segher Boessenkool wrote:
> 
> > > 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

Re: Probing for native availability of isel from userspace

[malc]

On Sat, 22 Sep 2012, Gabriel Paubert wrote:

> On Sat, Sep 22, 2012 at 02:12:42PM +0400, malc wrote:
> > On Sat, 22 Sep 2012, Segher Boessenkool wrote:
> > 
> > > > 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

Re: Probing for native availability of isel from userspace

[David Gibson]

On Sat, Sep 22, 2012 at 07:37:03PM +0400, malc wrote:
> On Sat, 22 Sep 2012, Gabriel Paubert wrote:
> 
> > On Sat, Sep 22, 2012 at 02:12:42PM +0400, malc wrote:
> > > On Sat, 22 Sep 2012, Segher Boessenkool wrote:
> > > 
> > > > > 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

Re: Probing for native availability of isel from userspace

[Segher Boessenkool]

> Thanks for suggestion, but i'd rather not play with heuristics.

Have a look at /sys/kernel/debug/powerpc/emulated_instructions/ then?


Segher

Re: Probing for native availability of isel from userspace

[Benjamin Herrenschmidt]

On Sat, 2012-09-22 at 21:08 +0200, Segher Boessenkool wrote:
> > 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.

Re: Probing for native availability of isel from userspace

[malc]

On Sun, 23 Sep 2012, Benjamin Herrenschmidt wrote:

> On Sat, 2012-09-22 at 21:08 +0200, Segher Boessenkool wrote:
> > > 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 :-(
> 

Thank you.

-- 
mailto:av1474@comtv.ru

Re: Probing for native availability of isel from userspace

[Segher Boessenkool]

>> 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

Re: Probing for native availability of isel from userspace

[Gabriel Paubert]

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

Re: Probing for native availability of isel from userspace

[Benjamin Herrenschmidt]

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:
> > 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.

Re: Probing for native availability of isel from userspace

[Gabriel Paubert]

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:
> > 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.
> 
> 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.

Agreed.

	Cheers,
	Gabriel

Re: Probing for native availability of isel from userspace

[Benjamin Herrenschmidt]

On Mon, 2012-09-24 at 10:06 +0200, Gabriel Paubert wrote:
> > 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.
> > 
> > We should definitely advertise the availability of isel.
> 
> Agreed. 

If somebody has 5mn, patch welcome :-)

Cheers,
Ben.

Re: Probing for native availability of isel from userspace

[Segher Boessenkool]

>> 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

Re: Probing for native availability of isel from userspace

[Benjamin Herrenschmidt]

On Tue, 2012-09-25 at 15:17 +0200, Segher Boessenkool wrote:
> >> 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.

Re: Probing for native availability of isel from userspace

[Kumar Gala]

On Sep 25, 2012, at 3:59 PM, Benjamin Herrenschmidt wrote:

> On Tue, 2012-09-25 at 15:17 +0200, Segher Boessenkool wrote:
>>>> Fine. But I believe that mfpvr emulation came first, which is the =20=

>>>> 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=

>>> 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=

Re: Probing for native availability of isel from userspace

[Scott Wood]

On 09/22/2012 08:46:06 PM, Segher Boessenkool wrote:
>>> 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
>> 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=

Re: Probing for native availability of isel from userspace

[Benjamin Herrenschmidt]

On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> The ISA says that isel is "Category: Phased-In (sV2.06)" -- are there  
> any 2.06 chips that don't have it?

I believe "malc" is interested in knowing about pre-2.06 chips that have
it.

Cheers,
Ben.

Re: Probing for native availability of isel from userspace

[Scott Wood]

On 09/24/2012 07:32:03 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> > The ISA says that isel is "Category: Phased-In (sV2.06)" -- are =20
> there
> > 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=

Re: Probing for native availability of isel from userspace

[malc]

On Tue, 25 Sep 2012, Benjamin Herrenschmidt wrote:

> On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> > The ISA says that isel is "Category: Phased-In (sV2.06)" -- are there  
> > any 2.06 chips that don't have it?
> 
> I believe "malc" is interested in knowing about pre-2.06 chips that have
> it.
> 

That too, but also what 's' prefix means.

-- 
mailto:av1474@comtv.ru

Re: Probing for native availability of isel from userspace

[Scott Wood]

On 09/24/2012 07:47:28 PM, malc wrote:
> On Tue, 25 Sep 2012, Benjamin Herrenschmidt wrote:
>=20
> > On Mon, 2012-09-24 at 18:55 -0500, Scott Wood wrote:
> > > The ISA says that isel is "Category: Phased-In (sV2.06)" -- are =20
> there
> > > any 2.06 chips that don't have it?
> >
> > I believe "malc" is interested in knowing about pre-2.06 chips that =20
> have
> > 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=

Re: Probing for native availability of isel from userspace

[Segher Boessenkool]

>> 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