apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: Observations on fragmentation in SMS pools
Date Sun, 08 Jul 2001 09:22:17 GMT
> > 1. The good news is that allocations of small amounts
> >    of memory are very efficient.  They almost always
> >    take the fastest path through the code, in which
> >    some available space is reserved from the
> >    "sms->used_sentinel.prev" block with a handful of
> >    pointer arithmetic operations.


> >
> > 2. The bad news is that allocations for larger blocks
> >    (in the >=8KB range) typically require a call to the
> >    parent SMS to get data.  On my test machine, I'm seeing
> >    elapsed times in the 30 microsecond range when this
> >    happens, compared to less than 1 microsecond for small
> >    allocations that don't require more memory from the
> >    parent SMS.  And when an allocation falls through to
> >    the parent, it often seems to fall all the way through
> >    to the root SMS (I suspect that 30us includes a malloc).
> >    The problem seems to be particularly bad for things that
> >    create subrequests, like mod_include.

OK,not so cool.

> >
> > 3. The worse news is that there seems to be lot of
> >    fragmentation.  For example, I saw this pattern
> >    during a server-parsed request:

> >
> > For an SMS that's going to be a parent of other SMSs, we'll
> > need something with more sophisticated policies for reassigning
> > freed space than the current trivial-SMS.


> Yup.  I've brought this up to Sander and David before, but this is how

Really - first i've heard of it :(

> pools work EXCEPT for the fact that we get a little more pathological in
> SMS's addition of memory because each parent tacks on memory (as you
> described).  The optimization here is for the <4KB allocation.  I'm not
> sure that is what we need to be optimizing for.  More analysis is
> probably needed to see what our typical usage pattern is.  This is where
> Ian's pool replay code is *very* helpful (although I don't like adding
> more #ifdef to the pool code - yuck - I'd like to see a SMS that just
> prints that info and passes it up to the parent to do what it needs
> to).

Yep, i had a evry simple debug sms that simply printed out what it was
doing, then did it.  Maybe it's time to revive it, but it generates a LOT of

> Before turning SMS on in the mainline code by default, I think we need
> to come up with a more robust allocation algorithm.  And, the whole
> point of SMS is that we can play with memory allocation algorithms
> until we are blue in the face and nothing else changes.  You can't do
> that with the current pools code.  We need more people playing with it
> and suggesting new allocation algorithms.  =)

Absolutely.  This was my motivation in doing the work in the first place,
and it seems to be working.

> The trivial SMS tries to
> keep the memory allocation strategy as close as possible to what we
> currently have.

Oh, we're nowhere near ready to turn it on by default.  I never thought we
were, but you need a test case to prove/disprove what's going on, and that
what this whole pools as sms code gives us, a complex example that we can
use to improve our code :)

> Personally, I'd set MIN_FREE to 0 and bite the small allocations (now
> they'd be slow, but really, how many allocations are under 4KB - data
> structures, perhaps?).  I'd also like to see it smarter about reclaiming
> free space, but that gets really tricky.

Oh, if you look at it we do a LOT of allocations below 4K from pools.  Turn
on the checking of every allocation and look at the sizes being requested.

> It's a tradeoff (and is purposeful for lots of small allocations), but
> until someone can write a better memory allocation algorithm, this is
> what we got.  Trivial SMS has its Achilles heel here - this is just an
> aggrevation of how the original pool code works (the pool code would add
> 4KB, while each level of the SMS adds 4KB).

Well, we have what we have.  My main concern about trivial is that the code
gets complex, and im worried that we may be over complicating things for
ourselves.  KISS is aguiding principal that it never does any harm to follow

> Aaron pointed out that CLR (Cormen/Leiserson/Rivest for those that never
> took algorithms classes) has many memory allocation algorithms.  I'd
> bet we could find one that would work better.  -- justin

The sms code was added on May 9th, which looks like less than 2 months ago,
so to be honest we're in pretty damn good shape.  Let's take some time, do
the testing and define the problems then start looking at fixes.  Rushing in
with a lot of quick solutions won't get us anywhere but a world of hurt.


View raw message