Re: another problem with latest code drops

[Lachlan McIlroy <lachlan@sgi.com>]

Dave Chinner wrote:
> On Thu, Oct 16, 2008 at 05:38:39PM +1000, Lachlan McIlroy wrote:
>> Dave Chinner wrote:
>>> On Thu, Oct 16, 2008 at 12:06:21PM +1000, Lachlan McIlroy wrote:
>>>> fsstress started reporting these errors
>>>>
>>>> fsstress: check_cwd failure
>>>> fsstress: check_cwd failure
>>>> fsstress: check_cwd failure
>>>> fsstress: check_cwd failure
>>>> fsstress: check_cwd failure
>>>> ...
> ....
>>> Ah, yes. A shutdown in a directory transaction. Have you applied the
>>> fix to the directory block allocation transaction accounting that was one
>>> of the last patches I posted?
>> Yes, I checked that in yesterday and ran with it overnight.
> 
> OK.
> 
>>> If so, then there's some other problem in that code that we'll
>>> need a reproducable test case to be able to find....
>> I was running 8 copies of this command:
>> fsstress -p 64 -n 10000000 -d /mnt/data/fsstress.$i
>>
>> I tried it again but this time the system ran out of memory
>> and locked up hard.  I couldn't see why though - maybe a memory
>> leak.
> 
> I just ran up the same load in a UML session. I'd say it's this
> slab:
> 
>   2482   2481  99%    0.23K    146       17       584K xfs_btree_cur
> 
> which is showing a leak. It is slowly growing on my system
> and dropping the caches doesn't reduce it's size. At least it's
> a place to start looking - somewhere in the new btree code we
> seem to be leaking a btree cursor....
> 


I'm not seeing a leak in that slab - actually that slab doesn't even
show up.  I am seeing a lot of memory used here though:

116605669 116605669  26%    0.23K 6859157       17  27436628K selinux_inode_security