It only fails on firecracker whose default memory size is 128M.
For QEMU, if I set VM's memory to 128M, it also fails.
./scripts/build -j24 image=native-example && ./scripts/run.py -m 128M
trace:
OSv v0.53.0-87-gf7b6bee5
eth0: 192.168.122.15
Booted up in 345.76 ms
Hello from main
allocation 20000000 start
Unreasonable allocation attempt, larger than memory. Aborting.
[backtrace]
0x00000000403e29b4 <memory::reclaimer::wait_for_memory(unsigned long)+132>
0x00000000403e5da1 <???+1077829025>
0x00000000403e60b7 <???+1077829815>
0x00000000403e63f6 <malloc+70>
0x000010000140094f <???+20973903>
0x000000004042d39c <osv::application::run_main()+60>
0x000000004020dfe3 <osv::application::main()+147>
0x000000004042d568 <???+1078121832>
0x0000000040461be5 <???+1078336485>
0x00000000403f9fb6 <thread_main_c+38>
0x0000000040399e52 <???+1077517906>
0x9f01e98d66991fff <???+1721311231>
0x00000000403f997f <???+1077909887>
0x4156415741e58947 <???+1105561927>
Wonsup
2019년 9월 10일 화요일 오전 12시 35분 7초 UTC+9, Waldek Kozaczuk 님의 말:
>
> Interesting. I cannot reproduce the malloc() problem. I have no issues
> running your example with uncommented malloc:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/mman.h>
>
> int main()
> {
> size_t size = 512 * 1024 * 1024;
> printf("Hello from main\n");
> printf("allocation %lx start\n", size);
> int *p = (int *)malloc(size); // FAIL
> //int *p = (int *)mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE |
> MAP_ANONYMOUS, -1, 0); // OK
> printf("allocation %lx = %p\n", size, p);
> *(p) = 512;
> printf("access done\n");
>
> return 0;
> }
>
> OSv v0.53.0-107-g4f59f284
>
> eth0: 192.168.122.15
>
> Booted up in 135.90 ms
>
> Cmdline: /test_large --help
>
> Hello from main
>
> allocation 20000000 start
>
> allocation 20000000 = 0xffff800001b0d040
>
> access done
>
> As you can see the address returned is a virtual one. Can you email your
> thread stack trace when it crashes in your case?
>
> As far as why we commit the memory for all malloc I can not answer this
> and others might be able to address why it was designed like this.
>
> This might be a relevant issue -
> https://github.com/cloudius-systems/osv/issues/854. I guess we might
> change implementation of malloc_large() and for large sizes create a VMA
> like for mmap. But then malloc is used all over the place in kernel code so
> I wonder if we would not have issues like nested faults - see this -
> https://github.com/cloudius-systems/osv/issues/143 - it has some
> background between malloc() and mmap() handling in OSv.
>
> Waldek
>
> On Monday, September 9, 2019 at 7:41:31 AM UTC-4, pusno...@gmail.com
> wrote:
>>
>> Hi,
>> I found malloc returns physical address in mempool area and does not
>> perform demand paging (only mmap does).
>> Is there any reason for the design choice?
>> OSv fails, even if it only uses small portion of allocated memory.
>>
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <sys/mman.h>
>>
>> int main()
>> {
>> size_t size = 512 * 1024 * 1024;
>> printf("Hello from main\n");
>> printf("allocation %x start\n", size);
>> //int *p = (int *)malloc(size); // FAIL
>> int *p = (int *)mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE |
>> MAP_ANONYMOUS, -1, 0); // OK
>> printf("allocation %x = %p\n", size, p);
>> *(p) = 512;
>> printf("access done\n");
>>
>> return 0;
>> }
>>
>>
>> Thanks.
>>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/27528a92-b136-4f85-a914-647d55656613%40googlegroups.com.
