[memcached] bradfitz, r288: merge all trunk changes since tag 1.1.12... (fwd)

[Brad Fitzpatrick]

I believe I #ifdef'ed it out for now.  I understand your approach... I'll
make it a runtime option probably.


On Tue, 30 May 2006, Steven Grimm wrote:

> Brad Fitzpatrick wrote:
> > Modified: branches/facebook/ChangeLog
> > ...
> > +	* Brad Fitzpatrick <brad at danga.com>:  allocate 1 slab per class
> > +	on start-up, to avoid confusing users with out-of-memory errors
> > +	later.  this is 18 MB of allocation on start, unless max memory
> > +	allowed with -m is lower, in which case only the smaller slab
> > +	classes are allocated.
>
> That shouldn't be necessary any more if you're starting from the
> Facebook version of the code; I changed slabs.c so that it never gets
> those out-of-memory errors (at the cost of exceeding the maximum memory
> setting if you fill up your cache before you've allocated a slab of a
> particular class).
>
> Unfortunately preallocation doesn't play too well with the
> powers-of-less-than-2 slab allocation strategy, because if your slab
> class growth factor is low, you will end up with a hundred or more slab
> classes, and thus potentially a fair amount of wasted memory if you
> don't end up using all of them. That's why we went with our on-demand model.
>
> At the very least I think there should be a command-line switch to
> disable this for people who have fixed-size values and thus will only
> ever use one slab class. I don't think it should be left as a
> compile-time option because (using Facebook as an example) some of the
> memcached instances at a site can use fixed-size items while others
> don't, and having to keep track of two separate binaries isn't fun.
>
> -Steve
>
>