Re: Chunked mempools, a second verdict

On 4 May 2001, at 20:59, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Andres Kroonmaa wrote:
>
> > like what functions? Alloc/Free out of question, they are tuned for
> > performance, and any overhead is unwanted there. GetStats? Iterate?
> > We don't have much funcs left in fact. If we manage to make pools
> > selfcleaning, we'd loose currently best place: memPoolClean.
>
> memPoolClean is probably a good place, and it will still be there when
> pools are selfcleaning even if not visible in the external API.
>
> For the purpose in MemPools, simply sampling the time every N
> memPoolAlloc call (wher N could be 500 or any other arbitrary number)
> should be more than sufficient. What you are interested in is long term
> averages, not instant exact values.

 instant and exact no. But 1-5-10sec averages are quite interesting.

> I think making MemPools self adjusting by piggy back on
> memPoolAlloc/Free will only have a negliable impact on performance:
>
> if (!mem_stat_counter--)
> memPoolClean()

 yup. I initially leaned to that too. But 2 problems.
 Alloc rate can range from 1/min to 500K/sec. At one extreme we'd have
 time lag of few hundred minutes, at other we'd have heavy overhead,
 most problem being time lag.
 We can rely on lot of assumptions and try to selftune accoding, but
 after gone through all the pains to get the API style shining, this
 seems like a hacky path for timing purposes.
 We can additionally run memPoolClean() every N Alloc calls to try to
 stay in idle limits, but that is separate from timing stuff, imo.
 N probably quite high value. 1000 sort of minimum, I'd think of 10K
 and more. Then, when we have very high alloc rate, Clean is done more
 frequently, and during very light load Clean is done regularly from
 event.

> Note: A higher precision time can be emulated from the sampled time
> and mem_stat_counter.

 what do you mean, please explain?

> Also, I think the maxage argument of memPoolClean() should be made a
> tunable rather than a argument to the clean function, which in turns

 Initially, I wanted to implement some sort of selftuning for Clean
 rate. Currently, on my Cidera box, idle memory stays constantly within
 3-5M, no matter what limits. Unreferenced timeout of 15secs does the
 job. I think this timeout could drift between 5 and some 900 secs,
 depending on load and proximity to idle limits.

> calls for an extensible memPoolGlobalTune() call replacing
> memPoolSetIdleLimit and the maxage memPoolClean() argument.
>
> #define MEMPOOL_TUNE_IDLELIMIT 1
> #define MEMPOOL_TUNE_MAXAGE 2
> memPoolGlobalTune(int variable, int value)

 I'd agree on the API part. I think we will need some tunables.
 eg. that N might be wise to be made tunable.

 But maxage param to memPoolClean() can be used to say "release
 all idle chunks, and NOW". With only Tune function, we'd want
 to have Get function then as well. (getold set0 Clean setold).

 I'd also add memPoolTunePool(). One tunable is chunk size.
 I'd like to add Flags to pool, and tell memPools that some pools
 need not zero out returned Alloced object. When allocating large
 buffers for disk or network, where having cleared buffer is not
 needed, memset()'ing those wastes alot of CPU time.
 Probably one more flag to disable chunkbased pooling for a pool,
 and revert to xmalloc/xfree for that pool, while still gathering
 stats. We could create socalled anonymous pool, and convert all
 mallocs to use mempool with stats.
 How about idle limits per pool? In any case, extensible API would
 be nice.
 And if we add perpool Tune function, why not tag "global" somehow
 and use single API call for all?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri May 04 2001 - 16:14:45 MDT