On Mon, May 16, 2022 at 07:13:42AM -0700, Dave Hansen wrote: > On 5/14/22 18:20, Jarkko Sakkinen wrote: > > Looks like VMA's do not get merged properly: > ... > > 7f8f0800b000-7f8f08014000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f08014000-7f8f08025000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f08025000-7f8f08046000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f08046000-7f8f0804a000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f0804a000-7f8f0804b000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f0804b000-7f8f0804c000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f0804c000-7f8f0804d000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > 7f8f0804d000-7f8f0804e000 rw-s 00000000 00:05 84 /dev/sgx_enclave > > I remember some issue with VM_IO VMAs not getting merged, but I don't > remember how we fixed or addressed it. > > Seems like something we can and should fix, though. Access pattern here is series of small adjacent mmaps (brk()). During upstreaming vma_close callback was eliminated to allow VMA's getting merged. I'll try to trace the condition in the call path triggering this. BR, Jarkko
