Re: RFC: ABI support for special memory area

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Mar 1, 2017 at 8:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 02/28/2017 06:03 PM, H.J. Lu wrote:
>>
>> On Tue, Feb 28, 2017 at 8:19 AM, Carlos O'Donell <carlos@redhat.com>
>> wrote:
>>>
>>> On 02/23/2017 09:59 PM, H.J. Lu wrote:
>>>>>
>>>>> Why does it run _after_ all shared objects and the executable file are
>>>>> loaded?
>>>>
>>>>
>>>> Since __gnu_mbind_setup may call any external functions, it can only
>>>> be done after everything is loaded and relocated.
>>>
>>>
>>> Who defines this function?
>>
>>
>> Platform vendor with special memory support should provide such function.
>>
>>> Where is it implemented?
>>
>>
>> We are working on libmbind to implement it.
>
>
> That's backwards.  Either we need to merge libmbind in to glibc, or this
> should be something provided by the kernel vDSO.

I don't think libnuma belongs to glibc nor kernel.

> We certainly don't want to repeat the mistake with the unwinder and
> libgcc_s.

__gnu_mbind_setup is kind of like malloc.  The default __gnu_mbind_setup
in glibc just returns 0, which can be overridden by the one from libmbind.

>>> Why can't this be run in a constructor? Is that too late?
>>
>>
>> We can use MCDRAM for dynamically allocated memory with
>> memkind.  We are looking for a user-friendly way to use MCDRAM
>> for normal data variables.
>
>
> Is it really necessary to avoid the pointer indirection?

Yes.  We found that memkind wasn't sufficient.

-- 
H.J.