On Tue, May 21, 2019 at 12:57:47AM +0000, Roman Gushchin wrote: > On Mon, May 20, 2019 at 03:40:17PM +1000, Tobin C. Harding wrote: > > In an attempt to make the SMO patchset as non-invasive as possible add a > > config option CONFIG_DCACHE_SMO (under "Memory Management options") for > > enabling SMO for the DCACHE. Whithout this option dcache constructor is > > used but no other code is built in, with this option enabled slab > > mobility is enabled and the isolate/migrate functions are built in. > > > > Add CONFIG_DCACHE_SMO to guard the partial shrinking of the dcache via > > Slab Movable Objects infrastructure. > > Hm, isn't it better to make it a static branch? Or basically anything > that allows switching on the fly? If that is wanted, turning SMO on and off per cache, we can probably do this in the SMO code in SLUB. > It seems that the cost of just building it in shouldn't be that high. > And the question if the defragmentation worth the trouble is so much > easier to answer if it's possible to turn it on and off without rebooting. If the question is 'is defragmentation worth the trouble for the dcache', I'm not sure having SMO turned off helps answer that question. If one doesn't shrink the dentry cache there should be very little overhead in having SMO enabled. So if one wants to explore this question then they can turn on the config option. Please correct me if I'm wrong. The ifdef guard is there so memory management is not having any negative effects on the dcache/VFS (no matter how small). It also means that the VFS guys don't have to keep an eye on what SMO is doing, they can just configure SMO out. The dcache is already fairly complex, I'm not sure adding complexity to it without good reason is sound practice. At best SMO is only going to by mildly useful to the dcache so I feel we should err on the side of caution. Open to ideas. Thanks, Tobin.
