[Bug 230160] linuxulator doesn't implement madvise(MADV_DONTNEED) and any MADV_ flags with values >= 8 correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230160 --- Comment #6 from David Chisnall --- (In reply to Bill Sorenson from comment #5) `MADV_FREE` and Linux's `MADV_DONTNEED` have different use cases. For C, where malloc is called a lot more often than calloc, `MADV_FREE` provides much better semantics. For higher-level languages or for higher-security applications where we need to guarantee zero initialisation, `MADV_FREE` is useless because we have to `bzero` on either allocation or deallocation. As I said, at $WORK, we have a number of use cases where Linux's behaviour gives significantly better performance (less cache churn from redundant zeroing). We have to fall back to the zeroing behaviour when using anonymous shared memory though and that's a big perf hit for us. A `MADV_ZERO` would be a big win. Note, however, that `MADV_FREE` is currently broken in the Linuxulator, because the constant has a different value in FreeBSD and Linux and the Linuxulator just passes the flags through unmodified. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 230160] linuxulator doesn't implement madvise(MADV_DONTNEED) and any MADV_ flags with values >= 8 correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230160 --- Comment #7 from Bill Sorenson --- (In reply to David Chisnall from comment #6) I'm aware they have different use cases. My main point is that if we are going to adopt a Linux-MADV_DONTNEED equivalent we use Illumos' MADV_PURGE rather than invent a new argument. I don't object to adding MADV_PURGE or MADV_ZERO for Linux compatibility but to me it seems like it would usually be better to call munmap() directly than to use some bizarre madvise() semantics to simulate it although admittedly I don't know the specifics. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 230160] linuxulator doesn't implement madvise(MADV_DONTNEED) and any MADV_ flags with values >= 8 correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230160 --- Comment #8 from David Chisnall --- (In reply to Bill Sorenson from comment #7) As I said above, there is no mechanism for doing this with shared memory segments - we cannot zero pages in the middle of a shared-memory segment without using memset / bzero and this does not allow the kernel to decommit the physical pages. I haven't tested whether MAV_FREE allows the kernel to lazily replace the pages with zeroed pages, but for our uses we need to guarantee zeroing. On Linux you can do this with some forms of shared memory using fallocate to punch a hole in the underlying object, though apparently it isn't very reliable. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 230160] linuxulator doesn't implement madvise(MADV_DONTNEED) and any MADV_ flags with values >= 8 correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230160 --- Comment #9 from Mark Johnston --- (In reply to David Chisnall from comment #8) MADV_FREE has no effect on shared memory (or anything other than private anonymous memory); see vm_object_advice_applies(). We should update the man page to that effect. Aside from emulating Linux's MADV_DONTNEED, I'm not crazy about following the precedent set by Linux by adding a MADV_ZERO that is required to have specific side effects. msync(2) might be a better entry point for this functionality? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 234878] emulators/virtualbox-ose: Update to 6.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878 Tobias Kortkamp changed: What|Removed |Added Assignee|ports-b...@freebsd.org |v...@freebsd.org Keywords||needs-patch Summary|virtualemulators/virtualbox |emulators/virtualbox-ose: |-ose: Update to 6.0 |Update to 6.0 Flags||maintainer-feedback?(vbox@F ||reeBSD.org) CC||v...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
maintainer-feedback requested: [Bug 234878] emulators/virtualbox-ose: Update to 6.0
Tobias Kortkamp has asked v...@freebsd.org for maintainer-feedback: Bug 234878: emulators/virtualbox-ose: Update to 6.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878 ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
