On Fri 27-01-17 08:20:00, NeilBrown wrote: > 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. true and not much different from other reclaimable or movable objects. E.g. a pinned LRU page is also unmovable. > 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? I am not familiar with the [di]cache enough to comment on how easy would be to move those objects around. But there were already suggestions that LRU pages would be migrated before a long term pins to not block migration. Anyway this sounds like a topic on its own. From the current discussion so far it really seems that it would be really hard to define sensible semantic for GFP_TEMPORARY with the current implementation so I will send a patch to simply drop this flag. If we want to have such a flag then we should start over with defining the semantic first and think this thing over properly. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
