Re: another problem with latest code drops

[Dave Chinner <david@fromorbit.com>]

On Thu, Oct 16, 2008 at 06:35:03PM +1000, Lachlan McIlroy wrote:
> 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.

Overnight the xfs_btree_cur slab made it up to about 7000 in use
entries, so there is definitely a leak there, though it is a slow
one.

> I am seeing a lot of memory used here though:
>
> 116605669 116605669  26%    0.23K 6859157       17  27436628K selinux_inode_security

Ah - I don't run selinux. Sounds like a bug that needs reporting
to lkml...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com