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:


Well in that case in your argument your FADV_WRITE_START is of
the "waits for writeout then starts writeout if dirty" type.

In which case you've just made 3 consecutive  write+wait cycles
to the same page, so it is hardly an optimal IO pattern.
The point is, this is the interface that an app would want to use if they want _perfect_ IO patterns. 

I'll be annoying and take you up on this again.

It is possible that my FADV_WRITE_SYNC will do an extra write of a page
if it has since become dirty again, however that would seem to be rare
for such a thing to happen (ie. because the app has asked for some previous
copy of data to be on disk).

I'm not saying it would never happen, your sub-page sized example is one
probably valid case - however in that case Andrew's wait-for-write doesn't
always do the right thing either.

But I will grant that start-writeout + wait-for-write must be at least as
expressive as write-and-wait.

*however*, it still isn't perfect and it still does things worse than my
proposal. For example, if the kernel itself actually decides to start writeout
before you call fadvise(FADV_START_WRITEOUT) then it is now going to block
and wait for the io to finish.

Anyway if we agree they are both much of a muchness, then I hope we can
go for FADV_WRITE_ASYNC, FADV_WRITE_SYNC because it is consistent with the
rest of the userspace API we expose.

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