On Mon, May 13, 2013 at 05:14:00PM +1000, Dave Chinner wrote:

On Sun, May 12, 2013 at 10:13:21PM +0400, Glauber Costa wrote:

quoted

Initial notes: ==============

Mel, Dave, this is the last round of fixes I have for the
series. The fixes are few, and I was mostly interested in
getting this out based on an up2date tree so Dave can verify it.
This should apply fine ontop of Friday's linux-next.
Alternatively, please grab from branch "kmemcg-lru-shrinker" at:

	git://git.kernel.org/pub/scm/linux/kernel/git/glommer/memcg.git

Main changes from *v5: * Rebased to linux-next, and fix the
conflicts with the dcache.  * Make sure LRU_RETRY only retry
once * Prevent the bcache shrinker to scan the caches when
disabled (by returning 0 in the count function) * Fix i915
return code when mutex cannot be acquired.  * Only scan
less-than-batch objects in memcg scenarios

Ok, this is behaving a *lot* better than v5 in terms of initial
balance and sustained behaviour under pure inode/dentry press
workloads. The previous version was all over the place, not to
mention unstable and prone to unrealted lockups in the block
layer.

However, I'm not sure that the LRUness of reclaim is working
correctly at this point. When I switch from a write only workload
to a read-only workload (i.e. fsmark finishes and find starts), I
see this:

....

So, yeah, there's still some broken stuff in this patchset that
needs fixing.  The script that I'm running to trigger these
problems is pretty basic - it's the same workload I've been using
for the past 3 years for measuring metadata performance of
filesystems:

And unmounting an XFS filesystem after running this workload is
hanging from time to time due to a reference counting problem on a
buffer....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>