DragonFly kernel List (threaded) for 2008-01
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: objcache depot not used?
:Nicolas Thery wrote:
:> When an objcache is created, a pair of magazines is created for each
:> cpu (with mag_alloc()) and tied to each per-cpu cache. The depot is
:> initially empty. I can't find any other call to mag_alloc() and AFAIU
:> per-cpu caches always have 2 magazines. I therefore suppose that the
:> depot stays empty and is never used.
:>=20
:> is it intentional?
:
:I doubt. The object cache lacks certain things the bonwick 2001 paper ha=
:d=20
:(like dynamic magazine sizes, full or empty magazines only in the depot, =
:
:allocation of empty magazines on demand). We should write it properly at=
:=20
:some point. It just never was pressing enough.
:
:cheers
: simon
See line 536 or so of kern_objcache.c What happens is that,
ultimately, a magazine will become completely full of free items.
(full magazine == completely full of items available for
allocation).
When the two per-cpu magazines become full one will be moved
to the depot and an empty magazine will be recycled from the
depot.
Jeff's initial implementation only kept full magazines in the
depot. I may have made a few changes since then to deal with
corner cases but that is still essentially the idea.
I also ran statistics on it and it does appear to operate
as advertised... most allocations and frees stay in the per-cpu
area and never have to drop into the depot.
The only exception is the network mbuf case. Due to the way
the protocol stacks work it is possible to get a large flow of
mbufs moving from one cpu to another. The Objcache still does
a really excellent job, though.
We do not need to have dynamically sized magazines. They need
only be large enough to reduce the amount of contention on the
depot spinlock to unperceivable levels.
-Matt
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]