Re: [ATTEND] many topics

[Michal Hocko <mhocko@kernel.org>]

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>