lkml.org 
[lkml]   [2017]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: xgetbv nondeterminism
On Thu, Jun 15, 2017 at 8:05 PM, Andy Lutomirski <luto@kernel.org> wrote:
> 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?
>

Are you suggesting not to use vector in ld.so? We used to do that
several years ago, which leads to some subtle bugs, like

https://sourceware.org/bugzilla/show_bug.cgi?id=15128

Also x86-64 was the only target which used FOREIGN_CALL macros
in ld.so, FOREIGN_CALL macros were the cause of race condition
in ld.so:

https://sourceware.org/bugzilla/show_bug.cgi?id=11214



--
H.J.

\
 
 \ /
  Last update: 2017-06-16 06:34    [W:0.076 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site