On Thu, Jan 26 2017, Michal Hocko wrote: > On Thu 26-01-17 10:19:31, NeilBrown wrote: > >> I think it would be better if we could discard the idea of "reclaimable" >> and just stick with "movable" and "unmovable". Lots of things are not >> movable at present, but could be made movable with relatively little >> effort. Once the interfaces are in place to allow arbitrary kernel code >> to find out when things should be moved, I suspect that a lot of >> allocations could become movable. > > I believe we need both. There will be many objects which are hard to be > movable yet they are reclaimable which can help to reduce the > fragmentation longterm. Do we? Any "reclaimable" objects which are "busy", are really "unmovable" objects, and so contribute to fragmentation. I've been thinking about inodes and dentries - which usually come up as problematic objects in this context. It would be quite complex to support moving arbitrary inodes or dentries given the current design. But maybe we don't need to. Suppose these objects were allocated as 'movable', but when the first long-term reference was taken (i.e. the first non-movable reference), they were first moved to the "non-movable" region? Then we only need to be able to move a subset of these, which will often account for the bulk of the memory usage. There would be costs of course, but I think it might be worth pursuing. NeilBrown
Attachment:
signature.asc
Description: PGP signature
