Re: Strange memory leak in 2.6.x

[Alexander Nyberg <alexn@dsv.su.se>]

> > > for one of the last results of /proc/page_owner. It seems to be
> > > obvious that the memory-leak seems to be the first entry:
> > > 
> > >     $ less page_owner_sorted_20050314_0740.bz2
> > >     881397 times:
> > >     Page allocated via order 0
> > >     [0xc013962b] find_or_create_page+91
> > >     [0xf8aa9955] reiserfs_prepare_file_region_for_write+613
> > >     [0xf8aaa606] reiserfs_file_write+1366
> > >     [0xc015765c] vfs_write+172
> > >     [0xc015776c] sys_write+60
> > >     [0xc0103879] sysenter_past_esp+82
> > 
> > [resolved addresses => names]
> > > 
> > > The sorted table of /proc/kallsyms looks like this:
> > > 
> > >     f8aa96f0 t reiserfs_prepare_file_region_for_write       [reiserfs]
> > >     f8aaa0b0 t reiserfs_file_write  [reiserfs]
> > > 
> > > So I guess that we have a problem with the reiser filesystem??
> > > We are using reiserfs 3.6...
> > 
> > [added Vladimir Saveliev to CC]
> > 
> > The only thing that stands out is big page cache. However, looking at
> > the previous OOM output it shows that it is zone normal that is
> > completely out of memory and that highmem zone has lots of free memory.
> > 
> > Let's see if the big sharks know what is going on...
> 
> Hm, it seems like the big sharks are hunting other fishes at the moment...
> 
> I looked at the code myself - reiserfs_prepare_file_region_for_write
> has more then 250 lines of code. I don't want to critize anyone, but
> this function is a bit too long to be easily debugged.
> 
> Because we suspect the problem in reiserfs and we still have to reboot
> the machine every other day, we will switch to ext3 now.

Just to follow up, did the problems go away when switching to ext3?

Thanks
Alexander