xfs
[Top] [All Lists]

Re: possible deadlock in kmem_alloc (mode:0x50)

To: Chris Evert <chris@xxxxxxxxxx>
Subject: Re: possible deadlock in kmem_alloc (mode:0x50)
From: Nathan Scott <nathans@xxxxxxx>
Date: Tue, 12 Oct 2004 10:11:36 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <416AB1C1.30108@geodev.com>
References: <4159FFCC.9000708@geodev.com> <20040929111143.G4413387@wobbly.melbourne.sgi.com> <416AB1C1.30108@geodev.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.3i
On Mon, Oct 11, 2004 at 11:16:01AM -0500, Chris Evert wrote:
> Nathan Scott wrote:
> >
> >/proc/slabinfo will hold some clues, send it over this way.

Oh, another useful tidbit is /proc/meminfo.

> I bumped /proc/sys/vm/vfs_cache_pressure to 150 and that seemed to work 
> til this weekend.
> 
> A snapshot of /proc/slabinfo during this time:

Hmmm, well, these are your big slab users...

> slabinfo - version: 2.0
> # name            <active_objs> <num_objs> <objsize> <objperslab> 
> <pagesperslab> : tunables <batchcount> <limit> <sharedfactor> : slabdata 
> <active_slabs> <num_slabs> <sharedavail>
> ext3_inode_cache    6898  17840    512    8    1 : tunables   54   27 
>  8 : slabdata   2230   2230      0
> radix_tree_node    35085  46284    276   14    1 : tunables   54   27 
>  8 : slabdata   3306   3306      0
> inode_cache         2054   2080    384   10    1 : tunables   54   27 
>  8 : slabdata    208    208      0
> dentry_cache       10215  26468    152   26    1 : tunables  120   60 
>  8 : slabdata   1018   1018      0
> buffer_head       486022 486525     52   75    1 : tunables  120   60 
>  8 : slabdata   6487   6487      0

XFS seems to be playing ball and giving back slab cache memory
when asked to do so - ext3 is holding onto a fair bit, and I
can't tell who's used all those buffer heads - its the VMs
responsibility to get rid of those, with help from individual
filesystems.

cheers.

-- 
Nathan


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