Open wjhun opened 6 years ago
samantha3pen
commented
3 years ago Hi @wjhun, my team members and I are students at the University of Texas at Austin. We are interested in contributing to Nanos as a part of a project for our virtualization class. Is this issue still available for us to work on? Could we take on this issue?
wjhun
commented
3 years ago Hi @wjhun, my team members and I are students at the University of Texas at Austin. We are interested in contributing to Nanos as a part of a project for our virtualization class. Is this issue still available for us to work on? Could we take on this issue?
Hello @samantha3pen. Yes, you may take on this issue. I'm still jogging my memory on this one, but I think this would merely involve switching bootstrap allocs and deallocs over to the locked kernel heap once it's available. So basically bootstrap_alloc will do as it does until heaps.locked is nonzero, at which point the allocs and deallocs will be redirected to that heap.
It's fine to leak the initial bootstrap allocations, but it doesn't make sense to leak after init, so please also implement the bootstrap dealloc, which would be a no-op if the allocation is within the span of bootstrap_region or otherwise deallocate from heaps.locked.
samantha3pen
commented
3 years ago Hello @samantha3pen. Yes, you may take on this issue. I'm still jogging my memory on this one, but I think this would merely involve switching bootstrap allocs and deallocs over to the locked kernel heap once it's available. So basically bootstrap_alloc will do as it does until heaps.locked is nonzero, at which point the allocs and deallocs will be redirected to that heap.
It's fine to leak the initial bootstrap allocations, but it doesn't make sense to leak after init, so please also implement the bootstrap dealloc, which would be a no-op if the allocation is within the span of bootstrap_region or otherwise deallocate from heaps.locked.
I've decided to work on a different issue at the moment, so if anyone else picks this up before I can get back to it, feel free.
francescolavra
commented
2 years ago Using the locked kernel heap for bootstrap allocs and deallocs is not possible because it can lead to a circular dependency if allocating from the locked heap triggers a new page allocation in an objcache (which in turn may need to allocate from the bootstrap heap). https://github.com/nanovms/nanos/pull/1633 makes the bootstrap heap size dependent on the total amount of physical memory, so that no unnecessary memory is consumed in low-memory machines, while allowing allocating all the available memory in machines with high amounts of memory. The bootstrap heap is still not growable (it may need to be growable if/when memory hotplug is supported).
The bootstrap heap is a small area in bss that's used for the earliest allocations and general allocations of the foundational system heaps, which in turn are used for subsequent allocations in the system. Most of that data would never be freed, so the heap just leaks on dealloc.
However, given that heaps which consume meta memory with use (like the id (bitmap) heap) live on the bootstrap, find some way to vector over the bootstrap allocate to use the general (mcache) heap later in init. A dealloc function could be added, then, which checks if the address is within the bss area, leaks if so, or otherwise hands the dealloc to general.
Then we'd never have to worry about running out of bootstrap memory or leaking memory. And the bootstrap size could be shrunk, knowing that bitmaps, etc., won't start growing until the alloc has been vectored over to general. Probably a 128KB or less area would suffice.