在 2013年2月7日星期四，Bryan Call 写道： > 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) > >
I'm outside now, please search mailing list with 'reclaimable freelist' keyword, I have given some articles links about the usage and design of reclaimable freelist in google doc and apache wiki. > -Bryan > > > > On Feb 3, 2013, at 7:28 PM, Yunkai Zhang <[email protected]<javascript:;>> > 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]<javascript:;>> > 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 > > -- Yunkai Zhang Work at Taobao
