lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: msync() behaviour broken for MS_ASYNC, revert patch?
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> Andrew Morton wrote:
> > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> >>But I've explained that they only matter for people using it in stupid ways.
> >>fsync also poses a performance problem for programs that call it after every
> >>write(2).
> >
> >
> > There's absolutely nothing stupid about
> >
> > *p = <expr>
> > msync(p, sizeof(*p), MS_ASYNC);
> >
>
> There really is if you're expecting a short time later to do
>
> *p = <expr2>
>
> and had no need for a MS_SYNC anywhere in the meantime.
> If you did have the need for MS_SYNC, then kicking off the IO
> ASAP is going to be more efficient.

Of course these sorts of applications don't know what they'll be doing in
the future. Often the location of the next update is driven by something
which came across the network.

> >>
> >>Is a more efficient implementation know-problematic?
> >
> >
> > It's less efficient for some things. A lot.
> >
>
> But only for stupid things, right?

No.

> >
> >>What applications did
> >>you observe problems with, can you remember?
> >
> >
> > Linus has some application which was doing the above. It ran extremely
> > slowly, so we changed MS_ASYNC (ie: made it "more efficient"...)
>
> Can he remember what it is? It sounds like it is broken.
>
> OTOH, it could have been blocking on pages already under writeout
> but a smarter implementation could ignore those (at the cost of
> worse IO efficiency in these rare cases).

There's no need to do that. Look:

msync(MS_ASYNC): propagate pte dirty flags into pagecache

LINUX_FADV_ASYNC_WRITE: start writeback on all pages in region which are
dirty and which aren't presently under writeback.

LINUX_FADV_WRITE_WAIT: wait on writeback of all pages in range.

I think that covers all conceivable scenarios. One thing per operation,
leave the decisions and tuning up to the application. And it gives us two
operations which are also useful in association with regular write().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-10 07:25    [from the cache]
©2003-2011 Jasper Spaans