On 2016-01-11 13:19, Felix Fietkau wrote: > 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. Yep, that was it. Fixed in r48200
- Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
