Re: zalloc project

--0000000000005f3d2f05c24eea08
Content-Type: text/plain; charset="UTF-8"

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

--0000000000005f3d2f05c24eea08
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi James.=C2=A0 =C2=A0Yes, I think removing zalloc is stil=
l worth doing as a clean-up.=C2=A0 Honestly I&#39;d like to also get rid of=
 objcache as well, replacing both zalloc and objcache with the new kmalloc_=
obj() facility.=C2=A0 I don&#39;t think this would be a beginner project, t=
hough, but you could take a look at it and see if you think=C2=A0you can do=
 it.=C2=A0 I&#39;ll explain the complexity.<div><br></div><div>For zalloc t=
here is a chicken-and-egg problem.=C2=A0 Currently three sub-systems still =
use zalloc:</div><div><br></div><div>SWAPMETA=C2=A0 =C2=A0- side-structures=
 used to manage swap space</div><div>PV ENTRY - side-structures used to man=
age page table pages</div><div>MAP ENTRY - side structures used to manage v=
irtual memory mappings</div><div><br></div><div>The main reason these subsy=
stems 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 exampl=
e is that bootstrapping the kernel VM system in early boot requires a numbe=
r of PV entries and map entry structures, but obviously those cannot be all=
ocated that early in the boot so they must be pre-reserved.=C2=A0 zalloc() =
has a mechanism to do this.=C2=A0 =C2=A0To implement this pre-reservation w=
ith kmalloc_obj() would require reserving at least one slab for each of the=
 three zones and enhancing the kmalloc_obj() subsystem to utilize the reser=
ve during early boot.=C2=A0 =C2=A0This part isn&#39;t difficult but it does=
 entail some significant programming.</div><div><br></div><div>For (B) an e=
xample 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-mem=
ory deadlock.=C2=A0 Similarly, if the pageout daemon is trying to page to s=
wap due to a low-memory condition it may have to allocate swap-meta structu=
res... 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 sid=
e-structures that might need to be incidentally allocated in low-memory sit=
uations, meaning that if the zalloc subsystem is converted to kmalloc_obj()=
, then kmalloc_obj() needs to be enhanced to maintain a few extra slabs rea=
dy to go.=C2=A0 =C2=A0I 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 th=
e demand.=C2=A0=C2=A0</div><div><br></div><div>So for (A) we would need a m=
echanism to register one or more full slabs with a zalloc_obj() zone, and f=
or (B) the zalloc_obj() function itself would pro-actively=C2=A0always try =
to maintain X extra slabs on its free list (non blocking, so in a low memor=
y situation it will try to maintain the additional zones but not block if i=
t can&#39;t).</div><div><br></div><div>So getting rid of zalloc is not triv=
ial.=C2=A0 zalloc deals with all of these situations and our current kmallo=
c_obj() facility does not.=C2=A0 Nor does objcache really.<br><div><div><br=
></div><div>-Matt</div></div></div></div>

--0000000000005f3d2f05c24eea08--