Making slab-allocated objects movable [LWN.net]

Making slab-allocated objects movable

Posted Apr 8, 2019 18:52 UTC (Mon) by ikm (guest, #493)
Parent article: Making slab-allocated objects movable

> The dentry cache implementation is relatively simple; rather than try to relocate cache entries, it simply frees those that have been targeted

This looks dubious. This hardcodes the decision that the cost of relocation multiplied by the probability that the node is going to be read later is smaller than a re-read of the entry from disk. I doubt that this is the place do make this sort of decision. Furthermore, this just looks semantically incorrect - if what is asked is relocation, than that is what should be done. Otherwise this could backfire in other possible use cases. For instance, suppose that for some reason the whole allocated space gets defragmented. Then, instead of the actual defragmentation, the whole dentry cache would be flushed, which is a completely different operation.

to post comments

Making slab-allocated objects movable

Posted Apr 9, 2019 7:17 UTC (Tue) by matthias (subscriber, #94967) [Link]

Maybe the intended meaning really is: "I need some space, please free these objects. If you cannot, then at least move them out of my view."

These functions will typically be called under memory pressure. Then reallocation cost can be quite high. Also, it should be easy to change the implementation in the future. It does not belong to the userspace interface. If one wants to implement a complete defrag at some time in the future, this should probably be changed. However, I do not really see a reason for a full defrag here. All objects in the dentry cache have the same size, so newly allocated entries can always go into existing holes.

Making slab-allocated objects movable

Posted Apr 9, 2019 14:21 UTC (Tue) by Paf (subscriber, #91811) [Link]

Reading through the associated email chain, Al makes *very* clear he views dentries and inodes as entirely unrelocatable. As a file system developer, I am inclined to agree. It would be quite difficult to put the necessary hooks to relocate these things in to any complex FS, especially when considering the VFS layer accesses that can happen in parallel. Freeing them is pretty tough too, but we’ve got that working because there’s no choice. Adding another complex thing like that doesn’t feel fun or especially worth it...

Making slab-allocated objects movable

Posted Apr 11, 2019 18:47 UTC (Thu) by clameter (subscriber, #17005) [Link]

The decision to relocate or to just zap an object is up to the slab cache and therefore to the subsystem. So its up to the one familiar with the subsystem to decide which strategy to get the object out of the way should be implemented. Thus there is no general scheme that could run into problems with one or the other slab cache.