I was briefly looking at the changes today. I will take a look more at them when I get some time.
There needs to be a decision if we are going to use ProxyAllocator or per-thread allocator in ink_freelist. Adding the ability to specify the size of the ProxyAllocator would be trivial to add. One way to determine what one to use is to benchmark them both and see what one is faster. Have you done any allocation benchmarks? Does the pre-thread implementation in the ink_freelist use atomics and how is it getting the thread id? (haven't looked at the code much for it yet) -Bryan On Feb 3, 2013, at 7:28 PM, Yunkai Zhang <[email protected]> wrote: > Hi Bryan, Leif, weijin: > > 1) There is a disadvantage of using ProxyAllocator to manage memory: It's > hard to configure the size of each ProxyAllocator pool, unsuitable size may > cause memory wast or bad performance. > > 2) The reclaimable freelist we pushed recently is implemented as > thread-local pool, feel free to try it. > > > On Mon, Feb 4, 2013 at 10:08 AM, weijin (JIRA) <[email protected]> wrote: > >> >> [ >> https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569953#comment-13569953] >> >> weijin commented on TS-1684: >> ---------------------------- >> >> good idea, the call ink_freelist_new/ink_freelist_free can be >> significantly reduced by making the ProxyAllocator as cache of global >> freelist. >> >>> Reduce the usage of global allocation/free lists - switch to using local >> thread allocation/free lists >>> >> ----------------------------------------------------------------------------------------------------- >>> >>> Key: TS-1684 >>> URL: https://issues.apache.org/jira/browse/TS-1684 >>> Project: Traffic Server >>> Issue Type: Improvement >>> Components: Core >>> Reporter: Bryan Call >>> >>> When running benchmarks ink_freelist_new() normally shows up as one of >> if not the number one function in the code using the most CPU. Currently >> ATS uses global free lists (via ClassAllocator<>, Allocator, and >> SparceClassAllocator<>) for memory allocation for some of its memory >> allocation. >>> Here is a list of how frequently the type of allocations are used and >> the "name" given to the allocator. This is a benchmark for a small object >> in cache fetched 100k times. >>> 400000 ink_freelist_new: hdrHeap >>> 300000 ink_freelist_new: hdrStrHeap >>> 203541 ink_freelist_new: ioBlockAllocator >>> 199616 proxy allocator thread_alloc: eventAllocator >>> 103554 ink_freelist_new: ioDataAllocator >>> 103554 ink_freelist_new: ioBufAllocator[5] >>> 100100 ink_freelist_new: ioAllocator >>> 100000 proxy allocator thread_alloc: hdrHeap >>> 100000 proxy allocator thread_alloc: cacheVConnection >>> 100000 ink_freelist_new: httpSMAllocator >>> 100000 ink_freelist_new: ArenaBlock >>> 18507 ink_freelist_new: mutexAllocator >>> 4772 ink_freelist_new: eventAllocator >>> 162 ink_freelist_new: cacheVConnection >>> 102 ink_freelist_new: netVCAllocator >>> 100 proxy allocator init thread_alloc: httpClientSessionAllocator >>> 100 ink_freelist_new: httpClientSessionAllocator >>> 1 proxy allocator thread_alloc: RamCacheCLFUSEntry >>> 1 ink_freelist_new: RamCacheCLFUSEntry >>> 1 ink_freelist_new: hostDBContAllocator >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> > > > > -- > Yunkai Zhang > Work at Taobao
