Re: [PATCH v2] Add malloc micro benchmark

[Carlos O'Donell <carlos at redhat dot com>]

On 01/05/2018 08:46 AM, Adhemerval Zanella wrote:
> 
> 
> On 05/01/2018 14:17, Carlos O'Donell wrote:
>> On 01/05/2018 07:50 AM, Adhemerval Zanella wrote:
>>>
>>>
>>> On 05/01/2018 12:32, Carlos O'Donell wrote:
>>>> On 01/04/2018 05:48 AM, Wilco Dijkstra wrote:
>>>>> Carlos O'Donell wrote:
>>>>>>
>>>>>> Don't use mallopt, please make it a tunable then.
>>>>>>
>>>>>> The mallopt API already had 2 secret arena options which eventually became
>>>>>> so well used they were baked into the API and had to be made public.
>>>>>
>>>>> Unfortunately tunables are not exported so you can't use them outside of GLIBC:
>>>>>
>>>>> /build/glibc/benchtests/bench-malloc-simple.o: In function `bench':
>>>>> bench-malloc-simple.c:(.text+0x19c): undefined reference to `__tunable_set_val'
>>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> Correct, we only have a env-var frontend right now, and the internal API is not
>>>> made accessible via GLIBC_PRIVATE.
>>>>
>>>> You have 3 options for tests:
>>>>
>>>> * Use the env vars to adjust test behaviour. Run the tests multiple times.
>>>> * Add a new C API frontend, very valuable, but more time consuming.
>>>> * Expose the existing internal C API via GLIBC_PRIVATE for testing, and throw
>>>>   it away later when we get a proper C API frontend.
>>>>
>>>
>>> Do we want a C API to tied the malloc implementation to some tunables? My
>>> understanding is the tunable api idea is not really enforce retro-compability
>>> (where a C api would enforce it).
>>  
>> If we add a C API to the tunables, we would honour that API for tunables for
>> all time, but the tunables themselves would not be stable.
>>
>> e.g.
>>
>> * get list of tunables supported
>> * get the default value for a tunable
>> * get the value of a tunable
>> * set the value of a tunable
>>
>> So you would use this API in the tests to get the tunable list, assert the
>> tcache tunable was accepted (or fail the test), and then set it to a special
>> value for the part of the test that needs it.
> 
> Right, this seems a reasonable approach (although I think out of the scope for
> this change).
 
That is up to Wilco to decide, but in general I agree that he need not take on
this work to get the current patch set merged, there are other solutions to the
need to tweak the settings. I think the env var and multiple test run approach
is going to be the simplest.

-- 
Cheers,
Carlos.