On Thu, Mar 25, 2010 at 05:17:23PM -0500, Christoph Lameter wrote: > On Wed, 24 Mar 2010, Andrea Arcangeli wrote: > > > On Wed, Mar 24, 2010 at 04:03:03PM -0500, Christoph Lameter wrote: > > > If a delay is "altered behavior" then we should no longer run reclaim > > > because it "alters" the behavior of VM functions. > > > > You're comparing the speed of ram with speed of disk. If why it's not > > acceptable to me isn't clear try booting with mem=100m and I'm sure > > you'll get it. > > Are you talking about the wait for writeback to be complete? Dirty pages > can be migrated. With some effort you could avoid the writeback complete > wait since you are not actually moving the page. It seems we're derailing, let's try to go back to the context. You said we can avoid get_page/put_page changes if we do like migration. Migration bails out if there's a gup reference on the page. It's _gup_ not writeback we're talking about. gup is used for I/O too like O_DIRECT (which is mandatory feature for virtual machines, if not for databases). So the I/O I'm talking about is the one that any driver or subsystem can do after calling gup. And it's not a lock on the page or a writeback bitflag, but the gup reference that we're waiting the I/O to complete, in order to be released. Not to tell drivers like old KVM pre-mmu-notifier that may never release the gup reference (these days any driver keeping gup references for "indefinite" time has to use mmu notifier to play nicely with the VM but there will always be temporary I/O at the speed-of-disk and hanging mprotect and mremap on that isn't ok with me). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>