Re: backing up ext4 fs, system unresponsive, thrashing like crazyeven though swap is unused

From: Dimitrios Apostolou
Date: Sun Dec 02 2012 - 07:44:09 EST


Hi, the problem in the quoted message still happens, shouldn't all of
ext4_inode_cache slab be emptied after "echo 3
> /proc/sys/vm/drop_caches"? In my case slab uses too much memory even
after all processes finish and system is in bad shape due to lack of
physical RAM. CC'ing tytso and Catalin Marinas since I've not been able
to track any leak with kmemleak.

Kernel is booted with slub_debug=,ext4_inode_cache, as this is the only
way to avoid for some time the following message. Nevertheless it has
not been able to show any leak.

kmemleak: Cannot allocate a kmemleak_object structure
kmemleak: Automatic memory scanning thread ended
kmemleak: Kernel memory leak detector disabled

Please have a look at the log (archived at [1]).

[1] http://lkml.indiana.edu/hypermail/linux/kernel/1211.3/00183.html


Thanks,
Dimitris


On Sun, 2012-11-25 at 17:03 +0200, Dimitrios Apostolou wrote:
> Hello list,
>
> on an old PIII-500MHz laptop, 128MB RAM, kernel 3.6.6, I started a
> backup process (tar|xz -4, nice'd and ionice'd -c3) from ext4 on local
> ATA disk to ext3 on external USB disk (USB-2.0 port on PCMCIA card).
> Even though earlier system load was minimal, free memory was plenty, the
> system now is unresponsive and is thrashing the disk, but the swapfile
> is rarely touched.
>
> I managed to get some information by renicing a root console to -20, but
> even then each keypress showed with a minimum 10s delay! In the attached
> file you can see the dmesg output, SysRq+{W,T}, ps, vmstat, slabs,
> meminfo.
>
> I think I'm seeing paging of executable pages because ext4_inode_cache
> is aggressively using all memory, evicting other pages. However under no
> condition should realtime processes be unresponsive. What do you think?
> Please note that I've set vm.swappiness to 0 and gradually increased
> vm.vfs_cache_pressure to 1000000, but see no difference.
>
>
> Thanks in advance,
> Dimitris
>
>
> P.S. Please CC me in all replies
>
>


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