From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 2/2] xfs: kick inode writeback when low on memory
Date: Tue, 12 Apr 2011 07:14:46 +1000
Message-ID: <20110411211446.GD21395@dastard>
References: <1302157196-1988-1-git-send-email-david@fromorbit.com>
 <1302157196-1988-3-git-send-email-david@fromorbit.com>
 <20110411183653.GD32346@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org
To: Christoph Hellwig <hch@infradead.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:26552 "EHLO
	ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1755575Ab1DKVOt (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 11 Apr 2011 17:14:49 -0400
Content-Disposition: inline
In-Reply-To: <20110411183653.GD32346@infradead.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Mon, Apr 11, 2011 at 02:36:53PM -0400, Christoph Hellwig wrote:
> How do you produce so many atime-dirty inodes?  With relatime we
> should have cut down on the requirement for those a lot.

Copy a bunch of files, then md5sum them.

The copy modifies c/mtime, the md5sum modifies atime, sees mtime is
younger than atime, updates atime and dirties the inode. i.e.:

$ touch foo
$ stat foo
  File: `foo'
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fe02h/65026d    Inode: 150756489   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
Access: 2011-04-12 07:08:24.668542636 +1000
Modify: 2011-04-12 07:08:24.668542636 +1000
Change: 2011-04-12 07:08:24.668542636 +1000
$ cp README foo
cp: overwrite `foo'? y
$ stat foo
  File: `foo'
  Size: 17525           Blocks: 40         IO Block: 4096   regular file
Device: fe02h/65026d    Inode: 150756489   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
Access: 2011-04-12 07:08:24.668542636 +1000
Modify: 2011-04-12 07:08:44.676108103 +1000
Change: 2011-04-12 07:08:44.676108103 +1000
$ md5sum foo
9eb709847626f3663ea66121f10a27d7  foo
$ stat foo
  File: `foo'
  Size: 17525           Blocks: 40         IO Block: 4096   regular file
Device: fe02h/65026d    Inode: 150756489   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
Access: 2011-04-12 07:09:00.223770431 +1000
Modify: 2011-04-12 07:08:44.676108103 +1000
Change: 2011-04-12 07:08:44.676108103 +1000
$

> Do you have traces that show if we're kicking off additional data
> writeback this way too, or just pushing timestamp updates into
> the AIL?

For the test workload, it just pushes timestamp updates into the AIL
as that is the only thing that is dirtying the inodes when the OOM
occurs. In other situations, I have no evidence either way, but
I have not noticed any performance changes from a high level.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com