tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kernel memory allocators
I've sometimes thought it would be worth supporting something a bit
like 'pools', but which don't contain any freelists (etc) - all
allocations being done from the 'global' (per cpu) malloc lists.
What they do give is pre-selection of the correct free list (for
fixed size items) and counts of allocates and frees.
Ideally items should be freed by reference to the same allocater,
but in practise that would only affect the stats.
Indeed 'pools' that don't contain pre-initialised items could
be implemented this way - giving lower overall memeory usage and
(probably) better cache usage (recently freed items are more
likely to be in the cache).
Separating these pools out from the ones that do use pre-
initialised items would be benefitial.
A couple of years ago 'pools' seemed to all the rage and lots
of them were defined - when all that was needed was a better
malloc! (which w probably now have).
The other thing I've seen is systems having separate free lists
for all multiples of 32 up to something like 1k (or even higher).
This is sort of pointless. If actual memory is obtained in (say)
8k pages, then you get nine 896 byte blocks or ten 800 byte blocks
in 8k - so there is no point having sizes other than 1024, 896,
800, 736, 672, 608 and multiples of 32 from then on.
David
--
David Laight: david%l8s.co.uk@localhost
Home |
Main Index |
Thread Index |
Old Index