On Tue, Nov 7, 2017 at 10:35 AM, Rick Payne <ri...@rossfell.co.uk> wrote:

> 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
> :)
>

Well, mapping huge (2MB) pages instead of small (4KB) pages is more
efficient (better use of the TLB cache), so when we have a large mmap()
bigger than a huge page, we definitely do want to use huge pages for it.
Adding mmap_small would work correctly, but the code which uses that memory
will run a bit slower as it's TLB cache may get filled more often. You can
definitely start with this patch though, if you remember it's just a hack.

For file maps, I guess we want page faults to be at the 4KB level, so we
want to use small pages.

Nadav.

-- 
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.

Reply via email to