From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753862AbXDDOPH (ORCPT ); Wed, 4 Apr 2007 10:15:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753866AbXDDOPH (ORCPT ); Wed, 4 Apr 2007 10:15:07 -0400 Received: from ns1.suse.de ([195.135.220.2]:52485 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753862AbXDDOPG (ORCPT ); Wed, 4 Apr 2007 10:15:06 -0400 Date: Wed, 4 Apr 2007 16:14:57 +0200 From: Andrea Arcangeli To: Dan Aloni Cc: Nick Piggin , Hugh Dickins , Andrew Morton , Linus Torvalds , Linux Memory Management List , tee@sgi.com, holt@sgi.com, Linux Kernel Mailing List Subject: Re: [rfc] no ZERO_PAGE? Message-ID: <20070404141457.GF19587@v2.random> References: <20070329075805.GA6852@wotan.suse.de> <20070330024048.GG19407@wotan.suse.de> <20070404033726.GE18507@wotan.suse.de> <20070404102407.GA529@wotan.suse.de> <20070404122701.GB19587@v2.random> <20070404135530.GA29026@localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070404135530.GA29026@localdomain> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 04, 2007 at 04:55:32PM +0300, Dan Aloni wrote: > How about applications that perform mmap() and R/W random-access on > large *sparse* files? (e.g. a scientific app that uses a large sparse > file as a big database look-up table). As I see it, these apps would > need to keep track of what's sparse and what's not... That's not anonymous memory if those are read page faults on _files_. I'm only talking about anonymous memory and do_anonymous_page, i.e. no file data at all. In more clear words, the only thing we're discussing here is char = malloc(1); *char. Your example _already_ allocates zeroed pagecache instead of the zero page, so your example (random access over sparse files with mmap, be it MAP_PRIVATE or MAP_SHARED no difference for reads) has never had anything to do with the zero page. If something we could optimize your example to _start_ using for the first time ever the ZERO_PAGE, it would make more sense to use it to be mapped where the lowlevel fs finds holes. ZERO_PAGE in do_anonymous_page instead doesn't make much sense to me, but it has always been there as far as I can remember. The thing is that it never hurted until the huge systems with nightmare cacheline bouncing reported heavy stalls on some testcase, which make it look like a DoS because of the ZERO_PAGE, hence now that it hurts I guess it can go.