All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>, Theodore Ts'o <tytso@mit.edu>,
	Matthew Wilcox <willy@infradead.org>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [ATTEND] many topics
Date: Fri, 27 Jan 2017 08:20:00 +1100	[thread overview]
Message-ID: <87tw8ltt6n.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170126085639.GA6590@dhcp22.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-01-26 21:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18  5:49 [ATTEND] many topics Matthew Wilcox
2017-01-18 10:13 ` [Lsf-pc] " Jan Kara
2017-01-18 11:26   ` willy
2017-01-18 13:32 ` Michal Hocko
2017-01-19 11:05   ` willy
2017-01-19 11:33     ` Michal Hocko
2017-01-19 11:52       ` willy
2017-01-19 12:11         ` Michal Hocko
2017-01-21  0:11           ` NeilBrown
2017-01-21 13:16             ` Theodore Ts'o
2017-01-22  4:45               ` NeilBrown
2017-01-23  6:05                 ` Matthew Wilcox
2017-01-23  6:30                   ` NeilBrown
2017-01-23  6:35                     ` Matthew Wilcox
2017-01-23 17:09                   ` Theodore Ts'o
2017-01-23 19:34                     ` NeilBrown
2017-01-25 14:36                       ` Vlastimil Babka
2017-01-25 20:36                         ` Matthew Wilcox
2017-01-25 21:15                           ` Vlastimil Babka
2017-01-25 23:19                         ` NeilBrown
2017-01-26  8:56                           ` Michal Hocko
2017-01-26 21:20                             ` NeilBrown [this message]
2017-01-27 13:12                               ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tw8ltt6n.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mhocko@kernel.org \
    --cc=tytso@mit.edu \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.