Re: [PATCH v2] Add malloc micro benchmark

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

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.

-- 
Cheers,
Carlos.