Re: atomic-free allocator
- From: Dmitriy Vyukov <dvyukov@xxxxxxxxx>
- Date: Tue, 29 Jan 2008 13:36:41 -0800 (PST)
On 29 янв, 23:01, Dmitriy Vyukov <dvyu...@xxxxxxxxx> wrote:
Multi-threaded memory allocator w/o atomic RMW operations or heavy
memory barriers. At all.
Basic outline:
Allocator created per thread. Local free operations use simple stack.
Remote free operations use mpsc-stack but with "hazard_cas" - cmpxchg
w/o lock prefix. So this mpsc-stack used only as "hint" - I assume
that I can find in this stack some nodes twice, and some nodes can
lost. To resurrect lost nodes I use "repair" operation. Repair simply
scan all nodes and search for lost nodes.
Main question - what will be loss rate (i.e. when hazard_cas() succeed
but node is not actually enqueued into stack). If loss rate is high
then we have to frequently repair block, to not lose too many nodes.
If loss rate is low than we can repair block rarely. Repair is
relatively expensive operation.
I test the allocator under sufficiently heavy load. On dual-core Intel
with shared L2 cache loss rate is about 0.01%, i.e. 1 lost node per
10000 successfully transfered nodes. So if I want to lose no more than
10 nodes, I can repair 1 time for every 100000 successful remote node
free() operations. I think it's very good results.
On quad-core Intel with 2 separete L2 caches loss rate is about 1%,
i.e. 1 lost node per 100 successfully transfered nodes. So if I want
to lose no more than 10 nodes, I can repair 1 time for every 1000
successful remote node free() operations. It's not so good.
So I think hybrid approach can be used.
For example. System with 2 processors and 8 hardware threads per
processor. hazard remote free operations can be used inside processor,
and accurate (with lock prefix) remote free operations can be used
between processors. So allocator will have 3 anchors - 1 for local
free, 1 for hazard remote free and 1 for accurate very remote free.
Dmitriy V'jukov
.
- References:
- atomic-free allocator
- From: Dmitriy Vyukov
- atomic-free allocator
- Prev by Date: Re: My first Proxy Collector /w a stack
- Next by Date: Re: appcore bug-fix...
- Previous by thread: Re: atomic-free allocator
- Index(es):
Relevant Pages
|