> > my 20c : it's easier to get more memory than more cpu - given
> > our effective single cpu limit at the moment.
In regards to CPU efficiency with malloc I think we'd get better
results if we reduce malloc/free rate per request. Currently we
do about 120 mallocs and 120 frees per each request, and consume
about 1-2% of CPU in total for that. Not much, considering rate.
For the defence of memory-efficiency I'd say it's easier to get
lots of GB of disk than it is to get RAM for supporting that.
Large disks are cheap, and squid is eating memory like hell.
This is limiting us in usable disk size quite alot already now.
Although I agree that CPU is also very precious.
In this regard, highres timings show that dlmalloc is faster than
even current memPools on average. So memPools are not a win in CPU,
at least not directly. Maybe without memPools dlmalloc would have
higher overhead, not sure.
On 19 Oct 2000, at 11:35, Chemolli Francesco (USI) <ChemolliF@GruppoCredit.it> wrote:
> My LIT 10 (0.5c): it would be however be nice if some
> big structures (say, the disk cache index) were somehow mmapped.
if you mean to use mmap for malloc, then this can be done. If you
mean to have mmaped file backing store for Store db, then this is
not so good idea, afaik.
------------------------------------
Andres Kroonmaa <andre@online.ee>
Delfi Online
Tel: 6501 731, Fax: 6501 708
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Thu Oct 19 2000 - 04:03:31 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:51 MST