<div dir="ltr">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.<div><br></div><div>For zalloc there is a chicken-and-egg problem.  Currently three sub-systems still use zalloc:</div><div><br></div><div>SWAPMETA   - side-structures used to manage swap space</div><div>PV ENTRY - side-structures used to manage page table pages</div><div>MAP ENTRY - side structures used to manage virtual memory mappings</div><div><br></div><div>The main reason these subsystems have not been converted is due to (A) bootstrapping in early-boot and (B) low-memory deadlock issues.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.  </div><div><br></div><div>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).</div><div><br></div><div>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.<br><div><div><br></div><div>-Matt</div></div></div></div>