[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?

On Fri, 10 Feb 2006, Nick Piggin wrote:
> This is a Linux implementation detail. As such it would make sense to
> introduce a new Linux specific MS_ flag for this.
> ..
> Definitely. And when the app gives us a hint that it really wants the
> data on the disk, starting it as early as possible is also a good
> optimisation.

But that's what MS_SYNC is. MS_SYNC says "I need this data written now".

MS_ASYNC moves it into the page cache. That makes 100% sense. Then it will
be written by the regular dirty page writeout. That makes 100% sense.

> I don't think there's anything wrong with your fadvise additions.
> I'd rather see MS_ASYNC start IO immediately and add another MS_
> flag for Linux to propogate bits.

Why? I miss the _reason_ you want to do this.

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".

In contrast, _your_ proposal is just inflexible and inconvenient.

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.

Your suggestion is no different from saying "we should make every
'write()' call start the IO". Which is obviously crap.

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: 2009-11-18 23:46    [W:0.095 / U:25.864 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site