[PATCH] memcached on FreeBSD...

[Sean Chittenden]

> > 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).

Cool.

> > What version of autofuck are you
> > guys depending on? 
> 
> autofuck is good. I'm not sure, I'll try build from CVS and see.

*gets shivers* I've spent too much time dorking with autoconf and
friends and dealing with the changing semantics between versions to
have anything nice to say about it, sorry.  :)

> > 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.

Ah, ok... I thought that it'd eventually free itself if there was
unused slabs.  Setting the H option in FreeBSD's _malloc_options will
internally call madvise(MADV_FREE) when free()'ing large hunks.  It's
an extra syscall, but it's better than swapping.

> 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.

FreeBSD uses brk(), regardless of the size.  It mmap()'s the
administrative structures for malloc'ed data, but that's it.  If bits
are never free()'ed, this is a pretty mute point and I'll go back to
lurking.

> > 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.

No, but by explicitly mmap()'ing non-anonymous regions, it's not
overly hard to do which could be nice for keeping a cache populated
across restarts, however, I have no use or desire that feature.  It
was more of an anecdotal bit from my webserver/proxy server writing
days and would be low hanging fruit that'd fall out of using mmap()
instead of relying on Linux's malloc.h bits.  :)

-sc

-- 
Sean Chittenden