Re: Chunked mempools, a first verdict

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Tue, 01 May 2001 16:39:00 +0200

I'd say the published API is getting close to what is required now.
There has been a 40% reduction in namespace from the original 25+7.

The statistics, maintenance and tuning still requires to be thought over
once more I think. As much of the logics as possible should be in lib.

and include/MemPool.h needs to be separated into internal and official
API stuff, preferably by having a #ifdef MEMPOOL_INTERNAL or something
similar. Remember: You can have official structure typedefs without
having the structure defined if the API only uses the structure as a
opaqueue pointer.

--
Henrik
Andres Kroonmaa wrote:
>  hmm. How much is normal? We have not just allocator. We have a module
>  that requires at least Init, Configure, Cleanup points, Cachemgr reports.
>  Due to its nature it needs periodic handler, Event. Because it is split
>  between lib/ where limited squid API exists and src/ it needs to share
>  some internal stuff between the 2 parts. Not even touching alloc part yet.
> 
>  I've done some work to reduce that messyness. But I don't see how
>  I can go much further.
> 
> lib/MemPool.o
> # public: 13
> unsigned int mem_pool_alloc_calls;   /* can drop, used in Info page
> unsigned int mem_pool_free_calls;    /* can drop, used in Info page
> void memArrayInit(Array *);          /* shared func
>   (we either share func, or global data, ala Pools)
> void memMeterSyncHWater(MemMeter *); /* used in mem.c for String pools
> void *memPoolAlloc(MemPool *);
> void memPoolClean(MemPool *, time_t); /* shared func
>   (needs to run in context of lib/ and yet be called from src/)
> MemPool *memPoolCreate(char *, size_t);
> void memPoolDestroy(MemPool *);
> void memPoolFlushMeters(MemPool *);  /* shared func
>   (need this both in lib/ internally and in src/ before reportings)
> void memPoolFree(MemPool *, void *);
> int memPoolInUseCount(MemPool *);    /* used in asserts in several places
> void memPoolShrink(MemPool *, ssize_t);   /* actually makes little sense
>   (chunked pool has little chance to shrink instantly)
> void memPoolTune(MemPool *, size_t, int); /* need that
> 
> src/MemPoolStats.o
> # public: 6
> void memCleanModule(); /* need
> void memConfigure();   /* need
> void memInitModule();  /* need
> void memPoolCleanIdlePools(void *); /* event handler
> size_t memPoolsTotalAllocated();    /* used in Info page
> void memReport(StoreEntry *);       /* cachemgr page
> 
>  We could create command func, ala mallopt() for both tuning and control,
>  is that preferred? Thats not've been practiced to date..
> 
>  Otherwise, I could drop these:
> unsigned int mem_pool_alloc_calls;
> unsigned int mem_pool_free_calls;
>  (but these are not added by me, so that would be interfering with someone)
> 
> void memPoolShrink(MemPool *, ssize_t);
>  which is quite useless for chunked version, mostly.
> 
> ------------------------------------
>  Andres Kroonmaa <andre@online.ee>
>  CTO, Delfi Online
>  Tel: 6501 731, Fax: 6501 708
>  Pärnu mnt. 158, Tallinn,
>  11317 Estonia
Received on Tue May 01 2001 - 08:39:23 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:58 MST