On 2016-01-11 12:57, Rafał Miłecki wrote: > I was looking at slabinfo and noticed something about uci. Executing > "uci commit" increases amount of "dentry" active objects. > > # echo 2 > /proc/sys/vm/drop_caches > > # egrep "dentry|kmalloc-64" /proc/slabinfo > dentry 559 2040 136 30 1 : tunables 120 60 8 : > sla > kmalloc-64 5357 9324 64 63 1 : tunables 120 60 8 : > sla > > # for N in `seq 1 1 1000`; do uci commit network; done > > # egrep "dentry|kmalloc-64" /proc/slabinfo > dentry 3540 3540 136 30 1 : tunables 120 60 8 : > sla > kmalloc-64 6457 9324 64 63 1 : tunables 120 60 8 : > sla > > # for N in `seq 1 1 1000`; do uci commit network; done > > # egrep "dentry|kmalloc-64" /proc/slabinfo > dentry 6570 6570 136 30 1 : tunables 120 60 8 : > sla > kmalloc-64 7587 9324 64 63 1 : tunables 120 60 8 : > sla > > This is not critical. As you know Linux kernel loves caching. When > amount of free RAM goes below ~2 MiB I can see kernel freeing dentry > objects and it doesn't OOM. > > But I'm still wondering if everything is OK. Is this normal kernel > keeps increasing pool of dentry objects as the result of "uci commit" > command? > > I expected "uci command" first to bump amount of active and total > dentry objects. Then when uci exits I expected amount of active > objects to go down. Kernel could reuse inactive objects during next > "uci commit" call. In such scenario amount of active objects would > vary, but amount of total object would be more-or-less stable. > > Can we be missing some (f)close in UCI? I checked uci_file_commit and > it looks alright. Or is this just how the filesystem works? I'm using > 3.18.21 (OpenWrt 15.05 branch) on device with serial flash (so JFFS2). User space programs are not required to close all their file descriptor, such a close happens implicitly on exit. I did an strace on uci commit without any delta, and I believe the likely cause is cached negative dentries for temporary files. On commit it checks a temp file before bailing out due to the lack of a config delta.
- Felix _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
