linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mm@kvack.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mel@csn.ul.ie>, Michal Nazarewicz <mina86@mina86.com>,
	Minchan Kim <minchan@kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages()
Date: Tue, 05 Mar 2013 14:47:40 +0100	[thread overview]
Message-ID: <5135F77C.9060706@samsung.com> (raw)
In-Reply-To: <201303050850.26615.arnd@arndb.de>

Hello,

On 3/5/2013 9:50 AM, Arnd Bergmann wrote:
> On Tuesday 05 March 2013, Marek Szyprowski wrote:
> > To solving this issue requires preventing locking of the pages, which
> > are placed in CMA regions, for a long time. Our idea is to migrate
> > anonymous page content before locking the page in get_user_pages(). This
> > cannot be done automatically, as get_user_pages() interface is used very
> > often for various operations, which usually last for a short period of
> > time (like for example exec syscall). We have added a new flag
> > indicating that the given get_user_space() call will grab pages for a
> > long time, thus it is suitable to use the migration workaround in such
> > cases.
>
> Can you explain the tradeoff here? I would have expected that the default
> should be to migrate pages out, and annotate the instances that we know
> are performance critical and short-lived. That would at least appear
> more reliable to me.

The problem is that the opposite approach is imho easier. get_user_pages()
is used in quite a lot of places (I was quite surprised when I've added some
debug to it and saw the logs) and it seems to be easier to identify places
where references are kept for significant amount of time. Usually such 
places
are in the device drivers. In our case only videobuf2 and some closed-source
driver were causing the real migration problems, so I decided to leave the
default approach unchanged.

If we use this workaround for every get_user_pages() call we will sooner or
later end with most of the anonymous pages migrated to non-movable 
pageblocks
what make the whole CMA approach a bit pointless.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center


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

  reply	other threads:[~2013-03-05 13:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05  6:57 Marek Szyprowski
2013-03-05  6:57 ` [RFC/PATCH 1/5] mm: introduce migrate_replace_page() for migrating page to the given target Marek Szyprowski
2013-03-05  6:57 ` [RFC/PATCH 2/5] mm: get_user_pages: use static inline Marek Szyprowski
2013-03-05  6:57 ` [RFC/PATCH 3/5] mm: get_user_pages: use NON-MOVABLE pages when FOLL_DURABLE flag is set Marek Szyprowski
2013-03-06  2:02   ` Yasuaki Ishimatsu
2013-03-06  9:30   ` Lin Feng
2013-03-06 10:53   ` Lin Feng
2013-05-06  7:19   ` Tang Chen
2013-05-07 10:47     ` Marek Szyprowski
2013-05-08  5:33       ` Tang Chen
2013-03-05  6:57 ` [RFC/PATCH 4/5] mm: get_user_pages: migrate out CMA " Marek Szyprowski
2013-03-06  2:41   ` Yasuaki Ishimatsu
2013-03-05  6:57 ` [RFC/PATCH 5/5] media: vb2: use FOLL_DURABLE and __get_user_pages() to avoid CMA migration issues Marek Szyprowski
2013-03-05  8:50 ` [RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages() Arnd Bergmann
2013-03-05 13:47   ` Marek Szyprowski [this message]
2013-03-05 19:59     ` Arnd Bergmann
2013-03-05 22:42 ` Daniel Vetter
2013-03-06  1:34 ` Yasuaki Ishimatsu
2013-03-06  8:47 ` Minchan Kim
2013-03-06 10:48   ` Marek Szyprowski
2013-03-06 11:57     ` Daniel Vetter

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=5135F77C.9060706@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=b.zolnierkie@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.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