[Top] [All Lists]

Re: xfs_inode slab

To: "Nikolay S." <nowhere@xxxxxxxxxxxxxxxx>
Subject: Re: xfs_inode slab
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 11 Feb 2013 08:06:52 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1360480449.4034.8.camel@xxxxxxxxxxxxxxxxx>
References: <1360480449.4034.8.camel@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Feb 10, 2013 at 11:14:09AM +0400, Nikolay S. wrote:
> Hello there,
> I see some bad behavior of xfs, which I can reproduce:
> 1. Create some directories and files on xfs volume (I use ~800000 files
> and 80000 directories on 4GB RAM system)
> 2. Create workload, that produces light page cache pressure (say, 4-8
> MB/s) and while pagecache eats all of free ram. I use the code from [1])
> 3. Stat all the objects on xfs volume
> The result depends on kernel version:
>       3.2) See kswapd struggling through D-state for several minutes.
>       3.7) See kswapd struggling through D-state forever

I can't reproduce it on any of my test boxes (range from 1GB to 8GB
RAM) on XFS or ext4. Indeed, this is a stress test I use
all the time (file creation, traversal and removal under page cache
pressure using 50-100 million files), and I haven't seen a stall for
a long time....

> Same steps on ext4 do not produce any bad results
> --
> [1]   https://bugzilla.kernel.org/show_bug.cgi?id=53031

Having looked at the bz, I don't see what XFS has to do with this
kswapd problem - it looks like it is THP/compaction related, and I
don't enable THP and/or compaction on my test machines. kswapd
is stuck deep in the VM on the page LRUs, so it doesn't look like an
XFS problem at all. If you turn off THP/compaction, does the problem
go away?


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>