Re: msync() behaviour broken for MS_ASYNC, revert patch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 :(


[email protected] 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".


MS_INVALIDATE



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 http://au.messenger.yahoo.com - 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux