[cap-talk] Another "core" principle - virtualizing memory

[Bill Frantz]

jwadams at gmail.com (Jonathan Adams) on Thursday, January 4, 2007 wrote:

>On 1/4/07, Jonathan S. Shapiro <shap at eros-os.com> wrote:
>>
>> On Wed, 2007-01-03 at 23:01 +0000, David Hopwood wrote:
>> > Nitpick: memory pools in general need not be used only for a single
>> > type, and may not be implemented as an array/vector. Their advantages
>> > come from separating allocations that should be independent of each
>> other,
>> > regardless of type or how the pool is implemented. It can also be a
>> > simplification to have different threads allocating from different
>> pools.
>>
>> Yes. In fact, early versions of BSD kmalloc were often partitioned by
>> the size of the allocated unit rather than the type. The introduction of
>> named pools (all elements of a pool required to be of same size) came
>> later.
>
>
>In Solaris, kmem_alloc() partitions by size (a pre-determined set of cache
>sizes), and kmem_cache_alloc() allows things more like "named" pools (with
>some handy additional features, like constructors and destructors), where
>all object have the same type and size.   Most highly-used structures come
>out of such caches.

To round out our trip down memory lane, in the 1970s, IBM's VM/370
kernel (called CP), used a number of fixed-size pools for small memory
allocations.  This approach made the more-common small allocations much
faster.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle 
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032