[
https://issues.apache.org/jira/browse/DISPATCH-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872450#comment-16872450
]
ASF GitHub Bot commented on DISPATCH-1372:
------------------------------------------
franz1981 commented on pull request #525: DISPATCH-1372 alloc_pool intrusive
linked list can be replaced by a linked stack
URL: https://github.com/apache/qpid-dispatch/pull/525#discussion_r297255900
##########
File path: src/alloc_pool.c
##########
@@ -164,14 +242,17 @@ void *qd_alloc(qd_alloc_type_desc_t *desc,
qd_alloc_pool_t **tpool)
desc->stats->held_by_threads += desc->config->transfer_batch_size;
#endif
for (idx = 0; idx < desc->config->transfer_batch_size; idx++) {
- item = DEQ_HEAD(desc->global_pool->free_list);
- DEQ_REMOVE_HEAD(desc->global_pool->free_list);
- DEQ_INSERT_TAIL(pool->free_list, item);
+ item = pop_stack(&desc->global_pool->free_list);
+ push_stack(&pool->free_list, item);
}
} else {
//
// Allocate a full batch from the heap and put it on the thread list.
//
+ //TODO(franz):
+ // - would be better to allocate in batches == transfer_batch_size
+ // and put a small (== sizeof(transfer_batch_size)) ref_count to
help the final free
+ // - could be beneficial directly to delink a chunk?
Review comment:
I need to explain it better IMHO. Let me rephrase something that I haven't
clarified yet on the JIRA.
The behaviour of this chunked stack is not actually the same of the original
one, in particular while "rebalancing" resources into/from the global free list.
I have chosen to just move `qd_alloc_item` between free lists, but not
`qd_alloc_chunk_t` on purpose, because:
- the purpose of `qd_alloc_chunk_t` is to cope with the allocation rate of
`qd_alloc_item` on a same thread
- to reduce the need to move "big" chunks between threads (causing
additional cache misses on the first attempt to access them)
- thread local lists are nearly bounded in size `localFreeListMax` ie can't
grow unbounded (maybe)
I'm not sure I've chosen right, that's the reason of the second comment ie
> could be beneficial directly to delink a chunk?
Maybe! I need a paper and a pencil to think about the implications of it and
which benefits will bring!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> alloc_pool intrusive linked list can be replaced by a linked stack
> ------------------------------------------------------------------
>
> Key: DISPATCH-1372
> URL: https://issues.apache.org/jira/browse/DISPATCH-1372
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Routing Engine
> Affects Versions: 1.8.0
> Reporter: Francesco Nigro
> Priority: Major
> Attachments: DOOM-3-BFG-Technical-Note.pdf,
> image-2019-06-21-11-08-17-015.png, image-2019-06-21-11-09-02-228.png,
> linked_list_misses.svg, stack_list_misses.svg
>
>
> alloc_pool is currently using a intrusive linked list approach to reduce the
> need of external data structures to hold data, saving expensive pointer
> chasing, but on modern architectures the data dependency between a current
> node and next/prev prevent the CPU prefetcher to stream nodes speculatively.
> There are different approaches that could benefit of prefetcing, but need to
> decouple the data stored from its container eg a linked stack.
> A linked stack is composed by doubly-linked chunks (allocated lazily) that
> make possible for the CPU to prefetch next/prev pointers given that those are
> already contained in the current chunk (if any).
> Although it seems counter-intuitive (given that introduce 1 more hop to reach
> the data), such data-structure is much more cache-friendly on modern
> architectures: I will attach some cache misses analysis to show it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
