diff options
Diffstat (limited to 'lib/libc')
| -rw-r--r-- | lib/libc/sys/madvise.2 | 27 | ||||
| -rw-r--r-- | lib/libc/sys/mmap.2 | 29 |
2 files changed, 56 insertions, 0 deletions
diff --git a/lib/libc/sys/madvise.2 b/lib/libc/sys/madvise.2 index 415af68..9a82782 100644 --- a/lib/libc/sys/madvise.2 +++ b/lib/libc/sys/madvise.2 @@ -58,6 +58,8 @@ The known behaviors are given in #define MADV_WILLNEED 3 /* will need these pages */ #define MADV_DONTNEED 4 /* don't need these pages */ #define MADV_FREE 5 /* data is now unimportant */ +#define MADV_NOSYNC 6 /* no explicit commit to physical backing store */ +#define MADV_AUTOSYNC 7 /* default commit method to physical backing store */ .Ed .Pp .Bl -tag -width MADV_SEQUENTIAL @@ -96,6 +98,31 @@ call. References made to that address space range will not make the VM system page the information back in from backing store until the page is modified again. +.It Dv MADV_NOSYNC +Request that the system not flush the data associated with this map to +physical backing store unless it needs to. Typically this prevents the +filesystem update daemon from gratuitously writing pages dirtied +by the VM system to physical disk. Note that VM/filesystem coherency is +always maintained, this feature simply ensures that the mapped data is +only flush when it needs to be, usually by the system pager. +.Pp +This feature is typically used when you want to use a file-backed shared +memory area to communicate between processes (IPC) and do not particularly +need the data being stored in that area to be physically written to disk. +With this feature you get the equivalent performance with mmap that you +would expect to get with SysV shared memory calls, but in a more controllable +and less restrictive manner. However, note that this feature is not portable +across UNIX platforms (though some may do the right thing by default). +For more information see the MAP_NOSYNC section of +.Xr mmap 2 +.It Dv MADV_AUTOSYNC +Undoes the effects of MADV_NOSYNC for any future pages dirtied within the +address range. The effect on pages already dirtied is indeterminate - they +may or may not be reverted. You can guarentee reversion by using the +.Xr msync 2 +or +.Xr fsync 2 +system calls. .El .Sh RETURN VALUES Upon successful completion, diff --git a/lib/libc/sys/mmap.2 b/lib/libc/sys/mmap.2 index 6e3619e..e165d32 100644 --- a/lib/libc/sys/mmap.2 +++ b/lib/libc/sys/mmap.2 @@ -150,6 +150,35 @@ stack top is the starting address returned by the call, plus .Fa len bytes. The bottom of the stack at maximum growth is the starting address returned by the call. +.It Dv MAP_NOSYNC +Causes data dirtied via this VM map to be flushed to physical media +only when necessary (usually by the pager) rather then gratuitously. +Typically this prevents the update daemons from flushing pages dirtied +through such maps and thus allows efficient sharing of memory across +unassociated processes using a file-backed shared memory map. Without +this option any VM pages you dirty may be flushed to disk every so often +(every 30-60 seconds usually) which can create performance problems if you +do not need that to occur (such as when you are using shared file-backed +mmap regions for IPC purposes). Note that VM/filesystem coherency is +maintained whether you use MAP_NOSYNC or not. This option is not portable +across UNIX platforms (yet), though some may implement the same behavior +by default. +.Pp +The +.Xr fsync 2 +function will flush all dirty data and metadata associated with a file, +including dirty NOSYNC VM data, to physical media. The +.Xr sync 1 +command and +.Xr sync 2 +system call generally do not flush dirty NOSYNC VM data. +The +.Xr msync 2 +system call is obsolete since +.Os BSD +implements a coherent filesystem buffer cache. However, it may be +used to associate dirty VM pages with filesystem buffers and thus cause +them to be flushed to physical media sooner rather then later. .El .Pp The |
