From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965080Ab3HHKTX (ORCPT ); Thu, 8 Aug 2013 06:19:23 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36962 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965043Ab3HHKSJ (ORCPT ); Thu, 8 Aug 2013 06:18:09 -0400 Date: Thu, 8 Aug 2013 12:18:07 +0200 From: Jan Kara To: Andy Lutomirski Cc: Dave Hansen , Jan Kara , linux-mm@kvack.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 0/3] Add madvise(..., MADV_WILLWRITE) Message-ID: <20130808101807.GB4325@quack.suse.cz> References: <20130807134058.GC12843@quack.suse.cz> <520286A4.1020101@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 07-08-13 11:00:52, Andy Lutomirski wrote: > On Wed, Aug 7, 2013 at 10:40 AM, Dave Hansen wrote: > > On 08/07/2013 06:40 AM, Jan Kara wrote: > >> One question before I look at the patches: Why don't you use fallocate() > >> in your application? The functionality you require seems to be pretty > >> similar to it - writing to an already allocated block is usually quick. > > > > One problem I've seen is that it still costs you a fault per-page to get > > the PTEs in to a state where you can write to the memory. MADV_WILLNEED > > will do readahead to get the page cache filled, but it still leaves the > > pages unmapped. Those faults get expensive when you're trying to do a > > couple hundred million of them all at once. > > I have grand plans to teach the kernel to use hardware dirty tracking > so that (some?) pages can be left clean and writable for long periods > of time. This will be hard. Right that will be tough... Although with your application you could require such pages to be mlocked and then I could imagine we would get away at least from problems with dirty page accounting. > Even so, the second write fault to a page tends to take only a few > microseconds, while the first one often blocks in fs code. So you wrote blocks are already preallocated with fallocate(). If you also preload pages in memory with MADV_WILLNEED is there still big difference between the first and subsequent write fault? > (mmap_sem is a different story, but I see it as a separate issue.) Yeah, agreed. Honza -- Jan Kara SUSE Labs, CR