Re: [RFC/PoC] malloc: use wfcqueue to speed up remote frees

[Mathieu Desnoyers via Libc-alpha <libc-alpha@sourceware.org>]

On 2023-01-17 01:42, Eric Wong wrote:
> Carlos O'Donell <carlos@redhat.com> wrote:
>>>> - Adding urcu as a build-time dependency is not acceptable for
>>>> bootstrap, instead we would bundle a copy of urcu and keep it
>>>> in sync with upstream. Would that make your work easier?
>>
>> Eric Wong wrote:
>>> Yes, bundling that sounds great.  I assume it's something for
>>> you or one of the regular contributors to work on (build systems
>>> scare me :x)
>>
>> Yes, that is something we'd have to do.
> 
> Hi, bringing this topic from 2018 up again (+Cc Mathieu):
> https://inbox.sourceware.org/libc-alpha/c061de55-cc2a-88fe-564b-2ea9c4a7e632@redhat.com/T/
> 
> I'm wondering if URCU-in-glibc is still on the table.  I'm also
> considering an learning C11 atomics and deriving a standalone
> wfcqueue w/o URCU atomics.

I've done a quick review of your proposed patch, and there is one thing 
that I'm concerned about: forward progress of remote_free_finish(). 
AFAIU, if we have a steady flow of remote_free_begin() calls, it can 
prevent forward progress of the anena owner.

When remote_free_step() captures the queue (splice) and processes it, it 
returns whether it has processed any elements, and the caller attempts 
to splice again if there was anything present. What I wonder is why is 
it required that the caller splices queue elements that were queued 
_after_ the begin of remote_free_finish() ? Can't we simply leave those 
to the next (eventual) remote_free_finish calls ?

If we do that change, this means remote_free_finish would only be needed 
when tearing down an arena, and upon allocation only a single call to 
remote_free_step() would be needed.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com