linux-kernel - Re: 2.6.39-rc4+: oom-killer busy killing tasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 May 2011 21:04:40 -0700 (PDT)
From:	Christian Kujau <lists@...dbynature.de>
To:	Dave Chinner <david@...morbit.com>
cc:	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	LKML <linux-kernel@...r.kernel.org>, xfs@....sgi.com,
	minchan.kim@...il.com
Subject: Re: 2.6.39-rc4+: oom-killer busy killing tasks

On Tue, 3 May 2011 at 10:51, Dave Chinner wrote:
> Can you run an event trace of all the XFS events during a find for
> me? Don't do it over the entire subset of the filesystem - only

You mean "event tracing", as in Documentation/trace/events.txt. For 
that I will have to enable CONFIG_FTRACE and CONFIG_FUNCTION_TRACER and 
probably others, right?

Looking at http://lwn.net/Articles/341899, I see CONFIG_EVENT_TRACING 
and the way to enable event tracing for "all events in fs/xfs" would be:

  echo 1 > /sys/kernel/debug/tracing/events/xfs/enable

> 100,000 inodes is sufficient (i.e. kill the find once the xfs inode
> cache slab reaches 100k inodes. While still running the event trace,
> can you then drop the caches (echo 3 > /proc/sys/vm/drop_caches) and
> check that the xfs inode cache is emptied? If it isn't emptied, drop
> caches again to see if that empties it. If you coul dthen post the
> event trace, I might be able to see what is going strange with the
> shrinker and/or reclaim.

Will try to do all that.

I wonder why nobody else is affected by this. Because nobody else runs 
powerpc or UP any more? I'm sure other people's filesystems are way bigger 
than mine, with much more inodes to cache...

Thanks for your time,
Christian. 
-- 
BOFH excuse #136:

Daemons loose in system.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/