On Wed, Apr 11, 2018 at 7:41 AM, cgxu519@xxxxxxx <cgxu519@xxxxxxx> wrote: > >> 在 2018年4月10日，下午1:38，Amir Goldstein <amir73il@xxxxxxxxx> 写道： >> >> On Tue, Apr 10, 2018 at 4:29 AM, cgxu519@xxxxxxx <cgxu519@xxxxxxx> wrote: >>> Hi guys, >>> >>> I’m a little curious for below code in ovl_lookup, is there any background for >>> copy stack instead of directly using it? >>> >>> memcpy(oe->lowerstack, stack, sizeof(struct ovl_path) * ctr); >>> >> >> Memory compaction. >> >> stack has ofs->numlower entries, which could be very large, >> but after lookup, oe->numlower can end up being much much >> smaller. Also, ovl_alloc_entry() packs lowerstack together with >> ovl_entry, so the overall memory usage of the long lived overlay >> dentry cache entries is lower. > > For regular file the maximum numlower is 1, so for optimizing memory > allocation/free maybe we can put one ovl_path entry inside ovl_entry > and allocate/deallocate ovl_entry via cache pool and for dir we can > link to ovl_path array from ovl_entry. Does it make sense? Yes. We can do it for dir as well if there's only one lower layer (it's going to be the common case). I suggest you look at dentry->d_name/d_iname for the implementation. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
