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

Andrew Morton wrote:

Nick Piggin <[email protected]> wrote:

If you want to start the IO *now* without waiting on it, call msync(MS_ASYNC)
If you don't want to start the IO now, that's really easy, do nothing.
If you want to start the IO now and also wait for it to finish, call msync(MS_SYNC)

I've already explained the problems with the start-io-in-MS_ASYNC approach.

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

Presently, the first option is unavailable.

We need to patch the kernel either way.  There's no point in going back to
either the known-problematic approach or to something half-assed.

The system call indicates to the kernel that IO submission should be started.
The earlier the kernel does that, the better (because it is likely that an
MS_SYNC is coming soon).

I think the current way of just moving the dirty bits is half-assed.

Is a more efficient implementation know-problematic? What applications did
you observe problems with, can you remember? Because the current behaviour
is also known-problematic for [email protected] (who are you anyway?)

--
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/

---

• Follow-Ups:
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>

• References:
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: [email protected]
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Nick Piggin <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Nick Piggin <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Nick Piggin <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Nick Piggin <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Nick Piggin <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Nick Piggin <[email protected]>
  • Re: msync() behaviour broken for MS_ASYNC, revert patch?
    • From: Andrew Morton <[email protected]>

• Prev by Date: Re: [PATCH] mm: Implement Swap Prefetching v23
• Next by Date: Re: [PATCH] mm: Implement Swap Prefetching v23
• Previous by thread: Re: msync() behaviour broken for MS_ASYNC, revert patch?
• Next by thread: Re: msync() behaviour broken for MS_ASYNC, revert patch?
• Index(es):
  • Date
  • Thread

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