On 03/11/2016 15:58, Andrew Jones wrote:
> Actually I have it envisioned the other way around. phys_alloc should
> only be for early allocations, before enabling the MMU (which is why
> it's called "phys"_alloc).
Yes, I agree. Putting your other suggestions together, you'd have for
early allocation:
phys // provide contiguous physical addresses
|
morecore // provide contiguous RAM
|
malloc // full API
Later, you'd switch morecore to also take care of installing PTEs:
page virt
\ /
morecore
|
malloc
Now morecore talks to both page and virt. page (alloc_page) is
initialized with whatever memory wasn't allocated by phys, and takes up
its job. virt (alloc_vpages) allocates virtual address space. morecore
is now taking not necessarily consecutive physical memory at page
granularity, assigning consecutive virtual address to it, and if needed
slicing pages into smaller allocations.
morecore is not an external API, it's just malloc's pluggable interface.
page/virt/malloc are all external APIs. phys could be, but nothing
uses phys_alloc_aligned and phys_zalloc_aligned so we might as well zap it.
Note that you can choose separately at each layer whether to implement
freeing or not. I think we only need to have it in "page" and "malloc"
(though in the latter it can be dummy, as it is now, since "malloc" is
just a small veneer around morecore).
>> addr = malloc_free;
>> available = malloc_top - addr;
>> if (available < size) {
>> if (vfree_bottom == malloc_top + 1) {
>> // can reuse top of previous segment
>> vsize = PAGE_ALIGN(size - available);
>> vaddr = alloc_vpages(vsize >> PAGE_SHIFT);
>> assert(vaddr == malloc_top + 1);
>> } else {
>> // ignore free space at end of previous segment
>> vsize = PAGE_ALIGN(size);
>> addr = vaddr =
>> alloc_vpages(vsize >> PAGE_SHIFT);
>> }
>> malloc_top = vaddr + vsize - 1;
>> }
>> malloc_free = addr + size;
>> return addr;
>
> I agree lib/x86/vm.c needs to change it's virtual address allocation
> scheme. It allocates down and never allows an address to be reused
> (but maybe that's by design to avoid TLB flushes?) I didn't feel like
> tackling that right now though. I'm not sure what the function you've
> written should be used for. To me, it looks like it's an extension of
> the virtual address management already available. Where do alloc_page()
> and install_page() come in, like vmalloc has?
The alloc_page()/install_page() loop would be before setting malloc_top.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
