Hi,
> I am not sure how this will help, as the later malloc() can still fail when
> it wants to allocate physically-contiguous memory.
>
> One hack you can try to fix
> https://github.com/cloudius-systems/osv/issues/854 and hopefully your issue
> is to change in core/mempool.cc, the function std_malloc(), replace the
>
> } else {
> ret = memory::malloc_large(size, alignment);
> }
>
> by something like (completely untested!)
I was just writing when yours arrived. I worked around it like this:
iff --git a/core/mmu.cc b/core/mmu.cc
index f929412..2296612 100644
--- a/core/mmu.cc
+++ b/core/mmu.cc
@@ -1454,7 +1454,7 @@ static initialized_anonymous_page_provider
page_allocator_init;
static page_allocator *page_allocator_noinitp = &page_allocator_noinit,
*page_allocator_initp = &page_allocator_init;
anon_vma::anon_vma(addr_range range, unsigned perm, unsigned flags)
- : vma(range, perm, flags, true, (flags & mmap_uninitialized) ?
page_allocator_noinitp : page_allocator_initp)
+ : vma(range, perm, flags | mmap_small, true, (flags & mmap_uninitialized)
? page_allocator_noinitp : page_allocator_initp)
{
}
I don't understand why file_vma is mmap_small whereas anon_vma isn't, but it
prevents the later assert. Whether its correct or not is another matter :)
> Unfortunately, I'm not familiar with this complex templated code, only Gleb
> is (CC'ed).
> Gleb, in commit 1b31de0e on of the changes you did was
>
> -inline u64 pt_element_common<N>::next_pt_pfn() const { return pfn(false); }
> +inline u64 pt_element_common<N>::next_pt_pfn() const {
> + assert(!large());
> + return pfn();
> +}
>
> Can you try to recall why you added this assert here (and in a couple of
> other places too). If this assert is really justified, do you have any guess
> what sort of bug may cause it to trigger?
I can get a better stack trace from the debug image, but it just shows slightly
more detail. I'd need to stare at the mmu code for quite a bit longer before I
get closer to understanding it - but the hack above has certainly allowed me to
get more memory in use.
Cheers,
Rick
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
