Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752349Ab0KQXwn (ORCPT ); Wed, 17 Nov 2010 18:52:43 -0500 Received: from THUNK.ORG ([69.25.196.29]:60798 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108Ab0KQXwm (ORCPT ); Wed, 17 Nov 2010 18:52:42 -0500 Date: Wed, 17 Nov 2010 18:52:30 -0500 From: "Ted Ts'o" To: Dave Chinner Cc: Michel Lespinasse , Peter Zijlstra , Nick Piggin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Rik van Riel , Kosaki Motohiro , Theodore Tso , Michael Rubin , Suleiman Souhlal Subject: Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback Message-ID: <20101117235230.GL3290@thunk.org> Mail-Followup-To: Ted Ts'o , Dave Chinner , Michel Lespinasse , Peter Zijlstra , Nick Piggin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Rik van Riel , Kosaki Motohiro , Theodore Tso , Michael Rubin , Suleiman Souhlal References: <1289996638-21439-1-git-send-email-walken@google.com> <1289996638-21439-4-git-send-email-walken@google.com> <20101117125756.GA5576@amd> <1290007734.2109.941.camel@laptop> <20101117231143.GQ22876@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101117231143.GQ22876@dastard> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1039 Lines: 21 On Thu, Nov 18, 2010 at 10:11:43AM +1100, Dave Chinner wrote: > I don't think ->page_mkwrite can be worked around - we need that to > be called on the first write fault of any mmap()d page to ensure it > is set up correctly for writeback. If we don't get write faults > after the page is mlock()d, then we need the ->page_mkwrite() call > during the mlock() call. OK, so I'm not an mm hacker, so maybe I'm missing something. Could part of this be fixed by simply sending the write faults for mlock()'ed pages, so page_mkwrite() gets called when the page is dirtied. Seems like a real waste to have the file system pre-allocate all of the blocks for a mlock()'ed region. Why does mlock() have to result in the write faults getting suppressed when the page is actually dirtied? - Ted -- 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/