Re: TLV to memPools

On 9 Oct 2001, at 10:59, Henrik Nordstrom <hno@squid-cache.org> wrote:

> > It could be used everywhere where alloc size is known at both alloc
> > time and free time, like is the case with TLV.
>
> I agree that there is need for a good "malloc()" replacement of untyped
> data. However, it is not clear to me where the proper balance is in this
> case.
>
> Things which need to be considered
> * Overhead in CPU
> * Overhead in memory usage
> * Robustness to coding errors
> * Robustness to code changes
> * Ease of coding

 * CPU overhead is least when type has dedicated Pool
 * MEM overhead is least when type has dedicated Pool
 * Robustness to coding errors is higest when type has dedicated Pool

 * Robustness to code changes is higest when we have abstract Pool
 * Ease of coding is higest when we have abstract Pool, although
   cbdata makes it so much simpler.

 But there is more to consider.
 I'm all for using dedicated pools for things that are used often or
 that are living long. The issue comes up with stuff that lives for
 around 100 cpu ticks and whose max concurrent usage is 1 or 0. Do we
 really need to create memPool for such, going to trouble doing so?
 We have currently about 90 pools in squid, of which typically ever
 used are 60, and on average inuse at a time of sampling are 50, and
 about 10 pools are ever used for less than 10 allocs. We can convert
 all allocs to dedicated pools, but would we care?

 For eg. would we care that TLV is using alloc sizes of MD5, SEntry's
 4xTimestamps, and variable URL? We know that those allocs exist only
 between MetaBuild and MetPack, ie. about 20 lines of C-code. We also
 know that they are all done per every swaplogdata. Why would we need
 a dedicated pool for each of these items?

 On the other hand, if we too eagerly start using abstract pools,
 tune them to be more granular, we add overhead and loose ability
 to notice high frequency and usage allocs, along with which type
 may be leaking.

 I think that major compromise must be made here. I wouldn't even
 object if it is decided "politically" to reject existence of abstract
 pools. For some data this is unavoidable, like variable length bufs,
 strings. But we can insist that each file implements its own set of
 pools. If this makes sense.

 Its actually simple to implement abstract pool ontop of cbdata,
 add API call cbdataAllocBestfit(size_t size) which picks between
 few pools or malloc(). We could even wrap xmalloc/xfree to use such
 cbdata call. And thats it, we could convert all xmallocs to cbdata.
 Would that be a good idea is another matter.

 In any case, if we even decide that abstract pools are cute, we need
 to make sure that important and frequently used types have dedicated
 pools. How would we make that sure? Would prog-guide be enough?

> The balance between these varies for different types of data. For most
> cbdata the balance is very strongly biased to the two robustness issues.
> For TLV the requirements is different. In fact, the requirements are
> different than from any other allocations we have as these are abstract
> typed allocations.

 Shouldn't focus on TLV at all. There are lots of others similar.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Oct 09 2001 - 06:17:29 MDT