[PATCH] memcached on FreeBSD...

[Anatoly Vorobey]

On Thu, Aug 21, 2003 at 12:00:53PM -0700, Sean Chittenden wrote:
> Howdy.  When are you guys planning on releasing 1.1.9?  

Hopefully in a few days. I'm finishing the sloppy queues feature 
(deleting expired items every 5 minutes or so instead of them taking
up space in memory until they're requested or pushed off), and with
Brad returning from his vacation soon, we'll intergrate it and call
it 1.1.9 (that was the plan anyway).

> What version of autofuck are you
> guys depending on? 

autofuck is good. I'm not sure, I'll try build from CVS and see.

> For 1.1.8, I had to gut the -k option since that's a Linux-ism (though
> I noticed the #ifdef's around the mlockall() calls in CVS).  Has any
> thought been given to using mmap(2) instead malloc(3)?  OSes are
> generally much better about actually free()ing data back to the OS if
> it's been mmap(2)'ed instead of using sbrk(2) (what most malloc(3)
> calls use internally).

We're only using malloc() to allocate chunks so large that it uses 
mmap(), not sbrk() (with a very few exceptions like read/write buffers
and connection structures, and we're reusing those so there's no real
fragmentation going on). We also never free() those large chunks, so 
again, no fragmentation.

The fact that malloc() uses mmap() rather than sbrk() to allocate large 
stuff is true in Linux (for chunks>64kb IIRC... we malloc() chunks of
1Mb anyway, presently), but I haven't verified it in FreeBSD. Is it
true in FreeBSD? If not, we might want to explicitly mmap() there, 
although this might turn out to be not really important, since we don't 
free and don't fragment.
 
> If you decide to mmap(2) non-anonymous files
> you could get a persistent cache almost for free by mmap(2)'ing actual
> files (of the hash ID of the objects?) and then use MAP_SHARED |
> MAP_NOCORE | MAP_NOSYNC.

Will anyone need a persistent memcache useful? I'm not certain about 
that.

-- 
avva@livejournal.com