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). -- Rafał _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
