Hi, I installed LTS 18.04 with headers. I'm trying to use the new flag MAP_SYNC with mmap call, but it complained MAP_SYNC undefined.What #define do I need to enable this? Thanks, David
On Tue, 17 Jul 2018 00:57:31 -0000, David Frank said:
I installed LTS 18.04 with headers. I'm trying to use the new flag MAP_SYNC with mmap call, but it complained MAP_SYNC undefined.What #define do I need to enable this?
You need more than a #define. You need a 4.15 kernel and matching kernel-headers. But if you installed 18.04 correctly, those should be in place already, as that apparently shipped with 4.15... Or if you're not really a kernel person, but a misplaced userspace person, 'man 2 mmap' tells us: NAME mmap, munmap - map or unmap files or devices into memory SYNOPSIS #include <sys/mman.h>
Thanks Valdis. Yes, I got the kernel and header files installed. But there seems to be a lot of mman.h. I found one in /usr/include/asm-generic that defined MAP_SYNC, and I included it also, now I got passed compile and linking. I'm checking out if the flag does what is is said to do-- I don't have to call msync function, which would boost performance. On Monday, July 16, 2018, 10:04:54 PM EDT, <valdis.kletnieks@vt.edu> wrote: On Tue, 17 Jul 2018 00:57:31 -0000, David Frank said:
I installed LTS 18.04 with headers. I'm trying to use the new flag MAP_SYNC with mmap call, but it complained MAP_SYNC undefined.What #define do I need to enable this?
You need more than a #define. You need a 4.15 kernel and matching kernel-headers. But if you installed 18.04 correctly, those should be in place already, as that apparently shipped with 4.15... Or if you're not really a kernel person, but a misplaced userspace person, 'man 2 mmap' tells us: NAME mmap, munmap - map or unmap files or devices into memory SYNOPSIS #include <sys/mman.h>_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 17 Jul 2018 02:15:17 -0000, David Frank said:
inking. I'm checking out if the flag does what is is said to do-- I don't have to call msync function, which would boost performance.
Note that this can actually *kill* performance, because this means that the kernel has to flush to backing store every single time it notes a change, whereas if you use msync only at those points your software needs a sync point, it can do it at only those points.... Thought experiment: Imagine a workflow that needs to checkpoint every 1000 changes to the shared segment (for instance, if you've mapped an array with 1000 rows, do a for() loop across it incrementing one item, and checkpoint when they're all incremented). msync after the loop completes is one sync, while a worst-case using MAP_SYNC could result in a flush after every single increment (if the system is rescheduling the process over and over - for instance, if there's also another syscall inside the loop).
Right. That makes sense. On Monday, July 16, 2018, 7:27:18 PM PDT, valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> wrote: On Tue, 17 Jul 2018 02:15:17 -0000, David Frank said:
inking. I'm checking out if the flag does what is is said to do-- I don't have to call msync function, which would boost performance.
Note that this can actually *kill* performance, because this means that the kernel has to flush to backing store every single time it notes a change, whereas if you use msync only at those points your software needs a sync point, it can do it at only those points.... Thought experiment: Imagine a workflow that needs to checkpoint every 1000 changes to the shared segment (for instance, if you've mapped an array with 1000 rows, do a for() loop across it incrementing one item, and checkpoint when they're all incremented). msync after the loop completes is one sync, while a worst-case using MAP_SYNC could result in a flush after every single increment (if the system is rescheduling the process over and over - for instance, if there's also another syscall inside the loop). _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (2)
-
David Frank -
valdis.kletnieks＠vt.edu