linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Gioh Kim <gioh.kim@lge.com>
Cc: jlayton@poochiereds.net, bfields@fieldses.org, vbabka@suse.cz,
	iamjoonsoo.kim@lge.com, viro@zeniv.linux.org.uk, mst@redhat.com,
	koct9i@gmail.com, minchan@kernel.org, aquini@redhat.com,
	linux-fsdevel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-mm@kvack.org, dri-devel@lists.freedesktop.org,
	akpm@linux-foundation.org, Gioh Kim <gurugio@hanmail.net>
Subject: Re: [PATCH 0/4] enable migration of driver pages
Date: Wed, 29 Jul 2015 11:49:45 +0100	[thread overview]
Message-ID: <20150729104945.GA30872@techsingularity.net> (raw)
In-Reply-To: <1436776519-17337-1-git-send-email-gioh.kim@lge.com>

On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> My ARM-based platform occured severe fragmentation problem after long-term
> (several days) test. Sometimes even order-3 page allocation failed. It has
> memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing
> and 20~30 memory is reserved for zram.
> 

The primary motivation of this series is to reduce fragmentation by allowing
more kernel pages to be moved. Conceptually that is a worthwhile goal but
there should be at least one major in-kernel user and while balloon
pages were a good starting point, I think we really need to see what the
zram changes look like at the same time.

> I found that many pages of GPU driver and zram are non-movable pages. So I
> reported Minchan Kim, the maintainer of zram, and he made the internal 
> compaction logic of zram. And I made the internal compaction of GPU driver.
> 

I am not familiar with the internals of zram but I took a look at what
it merged.  At a glance the compaction it implements and what you need are
are different in important respects. The core ability to move a zsmalloc
object is useful but the motivation of zram compaction appears to be
reducing the memory footprint. You need to reduce fragmentation which is
not the same. You could be faced with a situation where a full page in an
awkward place. Then there are three choices I can think of quickly and
probably more

1. You can move the whole page to another whole page and update all the
   references. This would play nicely with how compactions migrate and
   free scanner operates. However, you need free memory to move it

2. You could try moving the full page into other zsmalloc pages so that
   memory usage is also potentially reduced. This would work better with
   what Minchan intended but then there is the problem of discovery.
   Potentially it means though that another address space callback is
   required to nominate a target migration page

3. Hybrid approach. First trigger the zsmalloc compaction as it
   currently exists, then kick of compaction and move whole pages
   regardless of their content. The downside here is that it's expensive
   and potentially copies data multiple times but it's going to be
   easier to implement than 2.

1 would be the logical starting point, 3 is probably most effective even
if it's expensive and 2 is probably the best overall if the search costs
can be controlled.

This is a lot more complex than what balloon requires which is why I
would like to see it pinned down before new address_space operations are
created. Once they are created and drivers start using them then we lose
a lot of flexibilty and fixing the design becomes a lot harder.

With that in mind, I'll still read the rest of the series.

-- 
Mel Gorman
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>

  parent reply	other threads:[~2015-07-29 10:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13  8:35 [PATCH 0/4] enable migration of driver pages Gioh Kim
2015-07-13  8:35 ` [PATCH 1/4] fs/anon_inodes: new interface to create new inode Gioh Kim
2015-07-29 10:50   ` Mel Gorman
2015-07-13  8:35 ` [PATCH 2/4] mm/compaction: enable mobile-page migration Gioh Kim
2015-07-27 13:55   ` Vlastimil Babka
     [not found]     ` <55B63851.1080100-AlSwsSmVLrQ@public.gmane.org>
2015-07-27 18:56       ` Konstantin Khlebnikov
2015-07-28  0:21         ` Gioh Kim
2015-07-29 10:52   ` Mel Gorman
2015-07-31 10:43   ` Minchan Kim
2015-08-10  7:19     ` Minchan Kim
2015-07-13  8:35 ` [PATCH 3/4] mm/balloon: apply mobile page migratable into balloon Gioh Kim
2015-07-13  9:24 ` [PATCH 0/4] enable migration of driver pages Konstantin Khlebnikov
2015-07-13 10:02   ` Gioh Kim
     [not found] ` <1436776519-17337-1-git-send-email-gioh.kim-Hm3cg6mZ9cc@public.gmane.org>
2015-07-13  8:35   ` [PATCH 4/4] mm: remove direct calling of migration Gioh Kim
2015-07-27 13:58     ` Vlastimil Babka
2015-07-28  0:26       ` Gioh Kim
2015-07-13 14:20   ` [PATCH 0/4] enable migration of driver pages Rafael Aquini
2015-07-29 10:49 ` Mel Gorman [this message]
2015-07-29 10:55   ` Daniel Vetter
2015-07-29 12:16     ` Mel Gorman
2015-07-29 12:46       ` Daniel Vetter
2015-07-30  0:21         ` Gioh Kim

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=20150729104945.GA30872@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=aquini@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gioh.kim@lge.com \
    --cc=gurugio@hanmail.net \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jlayton@poochiereds.net \
    --cc=koct9i@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=mst@redhat.com \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).