| From: |
| Michal Hocko <mhocko-AT-kernel.org> |
| To: |
| NeilBrown <neilb-AT-suse.com> |
| Subject: |
| Re: [ATTEND] many topics |
| Date: |
| Fri, 27 Jan 2017 14:12:18 +0100 |
| Message-ID: |
| <20170127131218.GH4143@dhcp22.suse.cz> |
| Cc: |
| Vlastimil Babka <vbabka-AT-suse.cz>, Theodore Ts'o <tytso-AT-mit.edu>, Matthew Wilcox <willy-AT-infradead.org>, lsf-pc-AT-lists.linux-foundation.org, linux-fsdevel-AT-vger.kernel.org, linux-mm-AT-kvack.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>
