Messages in this thread | | | Date | Thu, 9 Feb 2006 21:50:40 -0800 | From | Andrew Morton <> | Subject | Re: 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: > > > >>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).
There's absolutely nothing stupid about
*p = <expr> msync(p, sizeof(*p), MS_ASYNC);
> > > >> 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?
It's less efficient for some things. A lot.
> 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"...) - 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/
| |