zalloc project

[Matthew Dillon]

Hi James.   Yes, I think removing zalloc is still worth doing as a
clean-up.  Honestly I'd like to also get rid of objcache as well, replacing
both zalloc and objcache with the new kmalloc_obj() facility.  I don't
think this would be a beginner project, though, but you could take a look
at it and see if you think you can do it.  I'll explain the complexity.

For zalloc there is a chicken-and-egg problem.  Currently three sub-systems
still use zalloc:

SWAPMETA   - side-structures used to manage swap space
PV ENTRY - side-structures used to manage page table pages
MAP ENTRY - side structures used to manage virtual memory mappings

The main reason these subsystems have not been converted is due to (A)
bootstrapping in early-boot and (B) low-memory deadlock issues.

For (A) an example is that bootstrapping the kernel VM system in early boot
requires a number of PV entries and map entry structures, but obviously
those cannot be allocated that early in the boot so they must be
pre-reserved.  zalloc() has a mechanism to do this.   To implement this
pre-reservation with kmalloc_obj() would require reserving at least one
slab for each of the three zones and enhancing the kmalloc_obj() subsystem
to utilize the reserve during early boot.   This part isn't difficult but
it does entail some significant programming.

For (B) an example would be... when a normal kmalloc() needs to allocate a
new block of memory it calls into the VM system which might also need to
allocate a PV entry or a MAP entry... which again calls kmalloc() again and
boom, low-memory deadlock.  Similarly, if the pageout daemon is trying to
page to swap due to a low-memory condition it may have to allocate
swap-meta structures... but in a low-memory situation that can deadlock as
well.

Dealing with these issues requires reducing the number of side-structures
that might need to be incidentally allocated in low-memory situations,
meaning that if the zalloc subsystem is converted to kmalloc_obj(), then
kmalloc_obj() needs to be enhanced to maintain a few extra slabs ready to
go.   I think implementing this enhancement to kmalloc_obj() would not be
too hard.. basically when kmalloc_obj() needs to allocate a new slab it
will check to see how many are on the free list and when there are not
enough it will pro-actively do non-blocking allocations ahead of the
demand.

So for (A) we would need a mechanism to register one or more full slabs
with a zalloc_obj() zone, and for (B) the zalloc_obj() function itself
would pro-actively always try to maintain X extra slabs on its free list
(non blocking, so in a low memory situation it will try to maintain the
additional zones but not block if it can't).

So getting rid of zalloc is not trivial.  zalloc deals with all of these
situations and our current kmalloc_obj() facility does not.  Nor does
objcache really.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20210514/eb203a9c/attachment.htm>