From: Arnd Bergmann <arnd@arndb.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
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, 5 Mar 2013 19:59:35 +0000 [thread overview]
Message-ID: <201303051959.35471.arnd@arndb.de> (raw)
In-Reply-To: <5135F77C.9060706@samsung.com>
On Tuesday 05 March 2013, Marek Szyprowski wrote:
> On 3/5/2013 9:50 AM, Arnd Bergmann wrote:
> > On Tuesday 05 March 2013, Marek Szyprowski wrote:
>
> The problem is that the opposite approach is imho easier.
I can understand that, yes ;-)
> 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.
But you said that most users are in device drivers, and I would expect drivers
not to touch that many pages.
We already have two interfaces: the generic get_user_pages and the "fast" version
"get_user_pages_fast" that has a number of restrictions. We could add another
such restriction to get_user_pages_fast(), which is that it must not hold
the page reference count for an extended time because it will not migrate
pages out.
I would assume that most of the in-kernel users of get_user_pages() that
are called a lot either already use get_user_pages_fast, or can be easily
converted to it.
Arnd
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
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, 5 Mar 2013 19:59:35 +0000 [thread overview]
Message-ID: <201303051959.35471.arnd@arndb.de> (raw)
In-Reply-To: <5135F77C.9060706@samsung.com>
On Tuesday 05 March 2013, Marek Szyprowski wrote:
> On 3/5/2013 9:50 AM, Arnd Bergmann wrote:
> > On Tuesday 05 March 2013, Marek Szyprowski wrote:
>
> The problem is that the opposite approach is imho easier.
I can understand that, yes ;-)
> 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.
But you said that most users are in device drivers, and I would expect drivers
not to touch that many pages.
We already have two interfaces: the generic get_user_pages and the "fast" version
"get_user_pages_fast" that has a number of restrictions. We could add another
such restriction to get_user_pages_fast(), which is that it must not hold
the page reference count for an extended time because it will not migrate
pages out.
I would assume that most of the in-kernel users of get_user_pages() that
are called a lot either already use get_user_pages_fast, or can be easily
converted to it.
Arnd
next prev parent reply other threads:[~2013-03-05 19:59 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-05 6:57 [RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages() Marek Szyprowski
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 ` 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 ` 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-05 6:57 ` Marek Szyprowski
2013-03-06 2:02 ` Yasuaki Ishimatsu
2013-03-06 2:02 ` Yasuaki Ishimatsu
2013-03-06 9:30 ` Lin Feng
2013-03-06 9:30 ` Lin Feng
2013-03-06 10:53 ` Lin Feng
2013-03-06 10:53 ` Lin Feng
2013-05-06 7:19 ` Tang Chen
2013-05-06 7:19 ` Tang Chen
2013-05-07 10:47 ` Marek Szyprowski
2013-05-07 10:47 ` Marek Szyprowski
2013-05-08 5:33 ` Tang Chen
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-05 6:57 ` Marek Szyprowski
2013-03-06 2:41 ` Yasuaki Ishimatsu
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 6:57 ` Marek Szyprowski
2013-03-05 8:50 ` [RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages() Arnd Bergmann
2013-03-05 8:50 ` Arnd Bergmann
2013-03-05 13:47 ` Marek Szyprowski
2013-03-05 13:47 ` Marek Szyprowski
2013-03-05 19:59 ` Arnd Bergmann [this message]
2013-03-05 19:59 ` Arnd Bergmann
2013-03-05 22:42 ` Daniel Vetter
2013-03-05 22:42 ` Daniel Vetter
2013-03-06 1:34 ` Yasuaki Ishimatsu
2013-03-06 1:34 ` Yasuaki Ishimatsu
2013-03-06 8:47 ` Minchan Kim
2013-03-06 8:47 ` Minchan Kim
2013-03-06 10:48 ` Marek Szyprowski
2013-03-06 10:48 ` Marek Szyprowski
2013-03-06 11:57 ` Daniel Vetter
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=201303051959.35471.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--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=m.szyprowski@samsung.com \
--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 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.