[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: msync() behaviour broken for MS_ASYNC, revert patch?
    Linus Torvalds wrote:
    > On Sat, 11 Feb 2006, Nick Piggin wrote:
    >>MS_INVALIDATE does that (in Linux),
    > I don't actually think it does.
    > In _current_ linux it does. In some other versions, it will have thrown
    > the dirty data away. Also, it will make subsequent accesses much much more
    > expensive - and it doesn't work on locked areas.
    >> the spec is poorly worded but the
    >>intention seems to be that it would push dirty state back into pagecache for
    >>implementations such as ours.
    > As an application writer, you'd be absolutely crazy to depend on that.

    Either the older versions of Linux are totally broken WRT the spec, or
    the spec totally broke compatibility. Either way I guess you would be
    crazy to depend on that :(

    >> has an application (database or logging I think), which
    >>uses MS_SYNC to provide integrity guarantees, however it is possible to do
    >>useful work between the last write to memory and the commit point. MS_ASYNC
    >>is used to start the IO and pipeline work.
    > So you're saying that there is one application that knows it could use
    > different semantics?
    > Now, please enumerate all the applications that use MS_ASYNC and prefer
    > the current semantics.
    > When you know that, you have an argument.

    I must have missed the post where you enumerated all said applications
    when changing from 2.4 and 2.5.67 behaviour to current.

    > In the meantime, you have an example of an application that wants _new_
    > semantics.

    2.4 semantics, actually. I have an example of a _regression_.

    >>>The current MS_ASYNC behaviour is the sane one. It's the one that doesn't
    >>>cause the harddisk to start ticking senselessly. It's the one that allows a
    >>>person on a laptop to say "don't write dirty data every 5 seconds - do it
    >>>just every hour".
    > Repeating something doesn't make it so.

    But it is so. Why did you change 2.0 semantics so much? Obviously because
    it was broken WRT the spec - I can tell you right now there could have been
    a whole lot of applications that preferred the semantics of just throwing
    out the data because it is faster, so it wasn't that.

    If you want to prove me wrong by quoting buggy behaviour from a 7 year old
    kernel.... how am I supposed to argue with that?

    >>>In contrast, _your_ proposal is just inflexible and inconvenient.
    >>Currently MS_ASYNC does the same as MS_INVALIDATE. But it used to start
    >>IO (before 2.5.something), and apparently it does in Solaris as well.
    > Actually, it did _not_ use to start IO.
    > Then, somebody made it do so, and people eventually screamed, and it was
    > reverted again.
    > Go check Linux-2.0 or something. You'll also see the "MS_INVALIDATE means
    > throw the dirty bit away" behaviour.

    Sounds like someone else must have screamed in 2.0 because it was buggy
    and the behaviour was changed to match standards for 2.4 and AFAIKS 2.2 does
    the same (although I'm not so good at reading 2.2 source).

    So those people who didn't like it must have been screaming for a long long
    time until it was finally changed in 2.5.68. Unfortunately we have someone
    else screaming now (and two years ago) because of the most recent change.

    > The _sane_ semantics are that if you say "MS_INVALIDATE" the dirty bit is
    > just thrown away. If you say "MS_INVALIDATE | MS_ASYNC", the dirty bit is
    > saved in the page cache and then the page is unmapped. And MS_SYNC
    > obviously does the same thing, except it also waits for it.

    They may sound sane to you but if you go throwing away the dirty bit
    against then standards then it is very broken.

    >>>If somebody really really wants to "start flushing data now", then he can do
    >>>so, but that actually has absolutely zero to do with "msync()" any more. A
    >>>person who wants the flushing to start "now" might want to flush any random
    >>>dirty buffers.
    >>I didn't quite understand what you're saying here.
    > I'm saying that "start flushing now" has _zero_ to do with an mmap.
    > It's a perfectly valid operation after a _write_ call too - even if you
    > never mmaped the area at all.
    > So if somebody wants to start background IO, what has that got to do with
    > msync()?

    It seems very obvious to me that it is a hint. If you wer expecting
    to call msync(MS_SYNC) at some point, then you could hope that hinting
    with msync(MS_ASYNC) at some point earlier might improve its efficiency.

    SUSE Labs, Novell Inc.
    Send instant messages to your online friends

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-02-10 18:40    [W:0.028 / U:6.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site