Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 8 Jul 2001 10:19:33 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: dean gaudet <dean@arctic.org>
Cc: Brian Pane <bpane@pacbell.net>, apr-dev@apache.org
Subject: Re: Observations on fragmentation in SMS pools
Message-ID: <20010708101933.Q28500@ebuilt.com>
References: <3B481014.80707@pacbell.net>
 <Pine.LNX.4.33.0107081013140.10441-100000@twinlark.arctic.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.33.0107081013140.10441-100000@twinlark.arctic.org>;
 from dean@arctic.org on Sun, Jul 08, 2001 at 10:14:16AM -0700

On Sun, Jul 08, 2001 at 10:14:16AM -0700, dean gaudet wrote:
> an ideal situation for free-lists (blocks of freed, but not free()d
> memory) is one per cpu.
> 
> a less ideal situation is one per thread.
> 
> an even less ideal situation is one per process (which requires locking).
> 
> it's insane to have one per pool :)

I think we're shooting for #2 (less ideal).  Unless someone can come up
with a way to dynamically tell how many CPUs we are running on and bind
a free-list to a specific CPU.

We're currently doing #3 (even less ideal) in apr_pools.c.  

And, yeah, the current trivial SMS is doing #4.  =)  But, don't expect it 
to stay like that.  And, if we implement the apr_sms_child_malloc, it
gets to somewhere between #2 and #3.  -- justin