Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1667390

Re: xgetbv nondeterminism

Show all headers | View raw

On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>> On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>>> On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen <dave.hansen@intel.com> wrote:
>>>>>>> On 06/14/2017 10:18 PM, Andy Lutomirski wrote:
>>>>>>>> Dave, why is XINUSE exposed at all to userspace?
>>>>>>>
>>>>>>> You need it for XSAVEOPT when it is using the init optimization to be
>>>>>>> able to tell which state was written and which state in the XSAVE buffer
>>>>>>> is potentially stale with respect to what's in the registers.  I guess
>>>>>>> you can just use XSAVE instead of XSAVEOPT, though.
>>>>>>>
>>>>>>> As you pointed out, if you are using XSAVEC's compaction features by
>>>>>>> leaving bits unset in the requested feature bitmap registers, you have
>>>>>>> no idea how much data XSAVEC will write, unless you read XINUSE with
>>>>>>> XGETBV.  But, you can get around *that* by just presizing the XSAVE
>>>>>>> buffer to be big.
>>>>>>
>>>>>> I imagine that, if you're going to save, do something quick, and
>>>>>> restore, you'd be better off allocating a big buffer rather than
>>>>>> trying to find the smallest buffer you can get away with by reading
>>>>>> XINUSE.  Also, what happens if XINUSE nondeterministically changes out
>>>>>> from under you before you do XSAVEC?  I assume you can avoid this
>>>>>> becoming a problem by using RFBM carefully.
>>>>>>
>>>>>>>
>>>>>>> So, I guess that leaves its use to just figuring out how much XSAVEOPT
>>>>>>> (and friends) are going to write.
>>>>>>>
>>>>>>>> To be fair, glibc uses this new XGETBV feature, but I suspect its
>>>>>>>> usage is rather dubious.  Shouldn't it just do XSAVEC directly rather
>>>>>>>> than rolling its own code?
>>>>>>>
>>>>>>> A quick grep through my glibc source only shows XGETBV(0) used which
>>>>>>> reads XCR0.  I don't see any XGETBV(1) which reads XINUSE.  Did I miss it.
>>>>>>
>>>>>> Take a look at sysdeps/x86_64/dl-trampoline.h in a new enough version.
>>>>>
>>>>> I wrote a test to compare latency against different approaches.   This
>>>>> is on Skylake:
>>>>>
>>>>> [hjl@gnu-skl-1 glibc-test]$ make
>>>>> ./test
>>>>> move    : 47212
>>>>> fxsave  : 719440
>>>>> xsave   : 925146
>>>>> xsavec  : 811036
>>>>> xsave_state_size: 1088
>>>>> xsave_state_comp_size: 896
>>>>>
>>>>> load/store is about 17X faster than xsavec.
>>>>>
>>>>> I put my hjl/pr21265/xsavec branch at
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=summary
>>>>>
>>>>> It uses xsave/xsave/xsavec in _dl_runtime_resolve.
>>>>
>>>> What is this used for?  Is it just to avoid clobbering argument regs
>>>> when resolving a symbol that uses an ifunc, or is there more to it?
>>>
>>> It is used for lazy binding the first time when an external function is called.
>>>
>>
>> Maybe I'm just being dense, but why?  What does ld.so need to do to
>> resolve a symbol and update the GOT that requires using extended
>> state?
>
> Since the first 8 vector registers are used to pass function parameters
> and ld.so uses vector registers, _dl_runtime_resolve needs to preserve
> the first 8 vector registers when transferring control to ld.so.
>

Wouldn't it be faster and more future-proof to recompile the relevant
parts of ld.so to avoid using extended state?

--Andy

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-15 07:20 +0200
  Re: xgetbv nondeterminism Dave Hansen <dave.hansen@intel.com> - 2017-06-15 16:40 +0200
    Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 00:20 +0200
      Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 00:50 +0200
        Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 00:50 +0200
          Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 01:20 +0200
            Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 01:30 +0200
              Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 04:20 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 05:10 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 06:40 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 18:10 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 18:20 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 18:40 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 19:50 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 20:00 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 20:10 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-17 08:30 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-17 15:00 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-17 18:40 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-17 21:50 +0200
      Re: xgetbv nondeterminism Dave Hansen <dave.hansen@intel.com> - 2017-06-16 01:40 +0200
        Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 04:30 +0200

csiph-web