On Fri, Apr 04, 2014 at 09:12:58AM +0200, Michael Kerrisk (man-pages) wrote: > > * Clearer intentions. Looking at the existing code and the code > > history, the fact that flags=0 behaves like flags=MS_ASYNC appears > > to be a coincidence, not the result of an intentional choice. > > Maybe. You earlier asserted that the semantics when flags==0 may have > been different, prior to Peter Zijstra's patch, > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=204ec841fbea3e5138168edbc3a76d46747cc987 > . > It's not clear to me that that is the case. But, it would be wise to > CC the developer, in case he has an insight. Right; so before that patch there appears to have been a difference. The code looked like: if (flags & MS_ASYNC) { balance_dirty_pages_ratelimited(); } else if (flags & MS_SYNC) { do_fsync() } else { /* do nothing */ } Which would give the following semantics: msync(.flags = 0) -- scan PTEs and update dirty page accounting msync(.flags = MS_ASYNC) -- scan PTEs and dirty throttle msync(.flags = MS_SYNC) -- scan PTEs and flush dirty pages However with the introduction of accurate dirty page accounting in .19 we always had an accurate dirty page count and both .flags=0 and .flags=MS_ASYNC turn into the same NO-OP. Yielding todays state, where 0 and MS_ASYNC don't do anything much and MS_SYNC issues the fsync() -- although I understand Willy recently posted a patch to do a data-range-sync instead of the full fsync. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
