Page MenuHomeFreeBSD

Enable vm map entry and object coalescing under mlockall(MCL_FUTURE)
ClosedPublic

Authored by alc on Jul 24 2018, 3:43 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 7 2024, 7:54 PM
Unknown Object (File)
Dec 29 2023, 3:26 AM
Unknown Object (File)
Dec 23 2023, 2:30 AM
Unknown Object (File)
Nov 25 2023, 5:58 AM
Unknown Object (File)
Nov 13 2023, 12:15 PM
Unknown Object (File)
Nov 6 2023, 4:46 AM
Unknown Object (File)
Oct 20 2023, 9:11 AM
Unknown Object (File)
Oct 19 2023, 10:54 PM
Subscribers

Details

Summary

vm_map_insert() first determines if the previous map entry's object can be extended, and then determines if the previous map entry can be extended. Testing prev_entry->eflags == protoeflags and the previous entry's wire count at first goes beyond determining whether the object can be extended.

To be clear, all that I am trying to achieve in vm_map_insert() is object coalescing. Later, when vm_map_wire() runs, it will coalesce the map entries, but that's not possible without the object coalescing in vm_map_insert().

I'm not proposing to commit the change to vm_mmap.c. That change made it easier to see the effects of the rest.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

You can see the effects of this change on ntpd.

Before:

921           0x200000           0x237000 r--   55  208   3   1 CN-- vn /usr/sbin/ntpd
921           0x237000           0x2c0000 r-x  137  208   3   1 CN-- vn /usr/sbin/ntpd
921           0x2c0000           0x2c7000 rw-    7    0   1   0 C--- vn /usr/sbin/ntpd
921           0x2c7000           0x2c8000 r--    1    1   1   0 CN-- df
921           0x2c8000           0x318000 rw-   80   80   1   0 C--- df
921        0x8002c0000        0x8002c8000 r--    8   37  75  25 CN-- vn /libexec/ld-elf.so.1
921        0x8002c8000        0x8002e1000 r-x   25   37  75  25 CN-- vn /libexec/ld-elf.so.1
921        0x8002e1000        0x8002e2000 rw-    1    0   1   0 C--- vn /libexec/ld-elf.so.1
921        0x8002e2000        0x8002e4000 rw-    2    2   1   0 C--- df
921        0x8002e4000        0x8002e5000 r--    1    1  27   0 ---- dv
921        0x8002e5000        0x8002f6000 r--   17   53   4   2 CN-- vn /lib/libm.so.5
921        0x8002f6000        0x800314000 r-x   30   53   4   2 CN-- vn /lib/libm.so.5
921        0x800314000        0x800315000 rw-    1    0   1   0 C--- vn /lib/libm.so.5
921        0x800315000        0x800316000 r--    1    0   1   0 CN-- vn /lib/libm.so.5
921        0x800316000        0x800317000 rw-    1    1   1   0 ---- df
921        0x800317000        0x800416000 r--  255  624   4   2 CN-- vn /lib/libcrypto.so.8
921        0x800416000        0x800550000 r-x  314  624   4   2 CN-- vn /lib/libcrypto.so.8
921        0x800550000        0x80055f000 rw-   15    0   1   0 C--- vn /lib/libcrypto.so.8
921        0x80055f000        0x80057a000 r--   27    0   1   0 CN-- vn /lib/libcrypto.so.8
921        0x80057a000        0x80057d000 rw-    3    3   1   0 C--- df
921        0x80057d000        0x800589000 r--   12   32   8   4 CN-- vn /lib/libthr.so.3
921        0x800589000        0x800599000 r-x   16   32   8   4 CN-- vn /lib/libthr.so.3
921        0x800599000        0x80059a000 rw-    1    0   1   0 C--- vn /lib/libthr.so.3
921        0x80059a000        0x80059b000 r--    1    0   1   0 CN-- vn /lib/libthr.so.3
921        0x80059b000        0x8005a7000 rw-   12   12   1   0 C--- df
921        0x8005a7000        0x80061f000 r--  120  456  87  37 CN-- vn /lib/libc.so.7
921        0x80061f000        0x800751000 r-x  306  456  87  37 CN-- vn /lib/libc.so.7
921        0x800751000        0x800757000 rw-    6    0   1   0 C--- vn /lib/libc.so.7
921        0x800757000        0x800760000 r--    9    0   1   0 CN-- vn /lib/libc.so.7
921        0x800760000        0x800987000 rw-  551  551   1   0 C--- df
921       0x10002c0000       0x10002e0000 rw-   32   32   1   0 C--- df
921       0x10002e0000       0x1000328000 rw-   72   72   1   0 C--- df
921       0x1000328000       0x100038c000 rw-  100  100   1   0 ---- df
921       0x100038c000       0x1000391000 rw-    5    5   1   0 ---- df
921       0x1000391000       0x1000398000 rw-    7    7   1   0 ---- df
921       0x1000398000       0x1000399000 rw-    1    1   1   0 ---- df
921       0x1000399000       0x10003a1000 rw-    8    8   1   0 ---- df
921       0x10003a1000       0x10003a4000 rw-    3    3   1   0 ---- df
921       0x10003a4000       0x10003a5000 rw-    1    1   1   0 ---- df
921       0x10003a5000       0x10003a8000 rw-    3    3   1   0 ---- df
921       0x10003a8000       0x10003ab000 rw-    3    3   1   0 ---- df
921       0x10003ab000       0x10003ae000 rw-    3    3   1   0 ---- df
921       0x10003ae000       0x10003af000 rw-    1    1   1   0 ---- df
921       0x10003af000       0x10003b0000 rw-    1    1   1   0 ---- df
921       0x10003b0000       0x10003b1000 rw-    1    1   1   0 ---- df
921       0x10003b1000       0x10003b2000 rw-    1    1   1   0 ---- df
921       0x10003b2000       0x10003b3000 rw-    1    1   1   0 ---- df
921       0x10003b3000       0x10003b4000 rw-    1    1   1   0 ---- df
921       0x10003b4000       0x10003b7000 rw-    3    3   1   0 ---- df
921       0x10003b7000       0x10003c0000 rw-    9    9   1   0 ---- df
921       0x10003c0000       0x10003c5000 rw-    5    5   1   0 ---- df
921       0x10003c5000       0x10003d6000 rw-   17   17   1   0 ---- df
921       0x10003d6000       0x10003e7000 rw-   17   17   1   0 ---- df
921       0x10003e7000       0x10003e8000 rw-    1    1   1   0 ---- df
921       0x10003e8000       0x10003f9000 rw-   17   17   1   0 ---- df
921       0x1000400000       0x1000a00000 rw- 1536 1536   1   0 C-S- df
921       0x1000a00000       0x1000c00000 rw-  512  512   1   0 --S- df
921     0x7fffdffbd000     0x7fffdffbe000 ---    0    0   0   0 ---- --
921     0x7fffdffbe000     0x7fffdffde000 ---    0    0   0   0 ---- --
921     0x7fffdffde000     0x7fffdfffe000 rw-   32   32   1   0 ---D df
921     0x7fffdfffe000     0x7fffdffff000 ---    0    0   0   0 ---- --
921     0x7fffdffff000     0x7ffffffdf000 ---    0    0   0   0 ---- --
921     0x7ffffffdf000     0x7ffffffff000 rw-   32   32   1   0 C--D df
921     0x7ffffffff000     0x800000000000 r-x    1    1  28   0 ---- ph

After:

927           0x200000           0x237000 r--   55  208   3   1 CN-- vn /usr/sbin/ntpd
927           0x237000           0x2c0000 r-x  137  208   3   1 CN-- vn /usr/sbin/ntpd
927           0x2c0000           0x2c7000 rw-    7    0   1   0 C--- vn /usr/sbin/ntpd
927           0x2c7000           0x2c8000 r--    1    1   1   0 CN-- df
927           0x2c8000           0x318000 rw-   80   80   1   0 C--- df
927        0x8002c0000        0x8002c8000 r--    8   37  66  22 CN-- vn /libexec/ld-elf.so.1
927        0x8002c8000        0x8002e1000 r-x   25   37  66  22 CN-- vn /libexec/ld-elf.so.1
927        0x8002e1000        0x8002e2000 rw-    1    0   1   0 C--- vn /libexec/ld-elf.so.1
927        0x8002e2000        0x8002e4000 rw-    2    2   1   0 C--- df
927        0x8002e4000        0x8002e5000 r--    1    1  24   0 ---- dv
927        0x8002e5000        0x8002f6000 r--   17   53   4   2 CN-- vn /lib/libm.so.5
927        0x8002f6000        0x800314000 r-x   30   53   4   2 CN-- vn /lib/libm.so.5
927        0x800314000        0x800315000 rw-    1    0   1   0 C--- vn /lib/libm.so.5
927        0x800315000        0x800316000 r--    1    0   1   0 CN-- vn /lib/libm.so.5
927        0x800316000        0x800317000 rw-    1    1   1   0 ---- df
927        0x800317000        0x800416000 r--  255  624   4   2 CN-- vn /lib/libcrypto.so.8
927        0x800416000        0x800550000 r-x  314  624   4   2 CN-- vn /lib/libcrypto.so.8
927        0x800550000        0x80055f000 rw-   15    0   1   0 C--- vn /lib/libcrypto.so.8
927        0x80055f000        0x80057a000 r--   27    0   1   0 CN-- vn /lib/libcrypto.so.8
927        0x80057a000        0x80057d000 rw-    3    3   1   0 C--- df
927        0x80057d000        0x800589000 r--   12   32   8   4 CN-- vn /lib/libthr.so.3
927        0x800589000        0x800599000 r-x   16   32   8   4 CN-- vn /lib/libthr.so.3
927        0x800599000        0x80059a000 rw-    1    0   1   0 C--- vn /lib/libthr.so.3
927        0x80059a000        0x80059b000 r--    1    0   1   0 CN-- vn /lib/libthr.so.3
927        0x80059b000        0x8005a7000 rw-   12   12   1   0 C--- df
927        0x8005a7000        0x80061f000 r--  120  456  77  33 CN-- vn /lib/libc.so.7
927        0x80061f000        0x800751000 r-x  306  456  77  33 CN-- vn /lib/libc.so.7
927        0x800751000        0x800757000 rw-    6    0   1   0 C--- vn /lib/libc.so.7
927        0x800757000        0x800760000 r--    9    0   1   0 CN-- vn /lib/libc.so.7
927        0x800760000        0x800987000 rw-  551  551   1   0 C--- df
927       0x10002c0000       0x10002e0000 rw-   32   32   1   0 C--- df
927       0x10002e0000       0x1000328000 rw-   72   72   1   0 C--- df
927       0x1000328000       0x1000400000 rw-  216  216   1   0 ---- df
927       0x1000400000       0x1000a00000 rw- 1536 1536   1   0 C-S- df
927       0x1000a00000       0x1000c25000 rw-  549  549   1   0 --S- df
927     0x7fffdffbd000     0x7fffdffbe000 ---    0    0   0   0 ---- --
927     0x7fffdffbe000     0x7fffdffde000 ---    0    0   0   0 ---- --
927     0x7fffdffde000     0x7fffdfffe000 rw-   32   32   1   0 ---D df
927     0x7fffdfffe000     0x7fffdffff000 ---    0    0   0   0 ---- --
927     0x7fffdffff000     0x7ffffffdf000 ---    0    0   0   0 ---- --
927     0x7ffffffdf000     0x7ffffffff000 rw-   32   32   1   0 C--D df
927     0x7ffffffff000     0x800000000000 r-x    1    1  25   0 ---- ph
vm/vm_map.c
1280 ↗(On Diff #45754)

Why _COW and not _NEEDS_COPY ?

vm/vm_map.c
1280 ↗(On Diff #45754)

Simply because it would be redundant. We always set both _COW and _NEEDS_COPY simultaneously, but we never clear _COW. I'm happy to add a KASSERT that _NEEDS_COPY isn't set below.

vm/vm_map.c
1280 ↗(On Diff #45754)

I do not understand why _COW without _NEEDS_COPY should block extending the entry.

vm/vm_map.c
1280 ↗(On Diff #45754)

Shadow objects have always been restricted to map (or overlay) a subset of or the entirety of the backing object, but never go beyond the end of the backing object.

Suppose that I had a region [A, C) and I fork. The child unmaps [B, C) and write faults on VA in [A, B). So, a shadow object is created, and _NEEDS_COPY is cleared. Now, the child revalidates [B, C) as what should be zero fill memory. If, however, we extended the shadow object, then the child's next access to [B, C) may see data from the parent.

To be clear, vm_object_coalesce() will also block this from happening because it doesn't allow coalescing if there is a backing object. I haven't tried to construct a scenario that relies entirely on _COW for correctness.

That said, there are almost certainly scenarios where we could safely remove _COW from the map entry, and we would see benefits in terms of fewer live map entries and objects.

This revision is now accepted and ready to land.Jul 24 2018, 8:06 PM

Add KASSERT that the previous entry does not have NEEDS_COPY set.

Test for virtual address contiguity before anything else. This change is motivated by my belief that the virtual address contiguity test is more likely than the eflags test to be false.

This revision now requires review to proceed.Jul 25 2018, 11:12 PM

Peter, could you please test this patch?

I've found a problem with guard entries. Peter, don't bother testing this version.

Take a more conservative approach.

Peter, can you please test this latest version.

In D16413#349184, @alc wrote:

Peter, can you please test this latest version.

Sure. Building a kernel right now.

I ran all of the stress2 tests on amd64 + a buildworld / installworld.
I tested the patch briefly on i386 and came across this unrelated problem: https://people.freebsd.org/~pho/stress/log/procstat.txt

This revision is now accepted and ready to land.Jul 27 2018, 8:36 PM

Kostik, Mark, do you have any questions or concerns about this latest version? I'm inclined to commit it.

In D16413#349521, @pho wrote:

I ran all of the stress2 tests on amd64 + a buildworld / installworld.
I tested the patch briefly on i386 and came across this unrelated problem: https://people.freebsd.org/~pho/stress/log/procstat.txt

Could you please post the kernel dump from this crash?

In D16413#349691, @alc wrote:

Kostik, Mark, do you have any questions or concerns about this latest version? I'm inclined to commit it.

Nothing from me, I accepted the revision just before your post. :)

In D16413#349521, @pho wrote:

I ran all of the stress2 tests on amd64 + a buildworld / installworld.
I tested the patch briefly on i386 and came across this unrelated problem: https://people.freebsd.org/~pho/stress/log/procstat.txt

Could you please post the kernel dump from this crash?

Never mind, this is trivial to reproduce.

This revision was automatically updated to reflect the committed changes.