From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
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>,
Arnd Bergmann <arnd@arndb.de>,
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: Wed, 6 Mar 2013 10:34:01 +0900 [thread overview]
Message-ID: <51369D09.8040103@jp.fujitsu.com> (raw)
In-Reply-To: <1362466679-17111-1-git-send-email-m.szyprowski@samsung.com>
2013/03/05 15:57, Marek Szyprowski wrote:
> Hello,
>
> Contiguous Memory Allocator is very sensitive about migration failures
> of the individual pages. A single page, which causes permanent migration
> failure can break large conitguous allocations and cause the failure of
> a multimedia device driver.
>
> One of the known issues with migration of CMA pages are the problems of
> migrating the anonymous user pages, for which the others called
> get_user_pages(). This takes a reference to the given user pages to let
> kernel to operate directly on the page content. This is usually used for
> preventing swaping out the page contents and doing direct DMA to/from
> userspace.
>
> 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.
>
> The proposed extensions is used by V4L2/VideoBuf2
> (drivers/media/v4l2-core/videobuf2-dma-contig.c), but that is not the
> only place which might benefit from it, like any driver which use DMA to
> userspace with get_user_pages(). This one is provided to demonstrate the
> use case.
>
> I would like to hear some comments on the presented approach. What do
> you think about it? Is there a chance to get such workaround merged at
> some point to mainline?
I'm interested in your idea since it seems that the idea solves my issue:
https://lkml.org/lkml/2012/11/29/69
So I want to apply your idea to a memory hot plug.
Thanks,
Yasuaki Ishimatsu
>
> Best regards
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
> Patch summary:
>
> Marek Szyprowski (5):
> mm: introduce migrate_replace_page() for migrating page to the given
> target
> mm: get_user_pages: use static inline
> mm: get_user_pages: use NON-MOVABLE pages when FOLL_DURABLE flag is
> set
> mm: get_user_pages: migrate out CMA pages when FOLL_DURABLE flag is
> set
> media: vb2: use FOLL_DURABLE and __get_user_pages() to avoid CMA
> migration issues
>
> drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 +-
> include/linux/highmem.h | 12 ++-
> include/linux/migrate.h | 5 +
> include/linux/mm.h | 76 ++++++++++++-
> mm/internal.h | 12 +++
> mm/memory.c | 136 +++++++++++-------------
> mm/migrate.c | 59 ++++++++++
> 7 files changed, 225 insertions(+), 83 deletions(-)
>
--
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: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
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>,
Arnd Bergmann <arnd@arndb.de>,
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: Wed, 6 Mar 2013 10:34:01 +0900 [thread overview]
Message-ID: <51369D09.8040103@jp.fujitsu.com> (raw)
In-Reply-To: <1362466679-17111-1-git-send-email-m.szyprowski@samsung.com>
2013/03/05 15:57, Marek Szyprowski wrote:
> Hello,
>
> Contiguous Memory Allocator is very sensitive about migration failures
> of the individual pages. A single page, which causes permanent migration
> failure can break large conitguous allocations and cause the failure of
> a multimedia device driver.
>
> One of the known issues with migration of CMA pages are the problems of
> migrating the anonymous user pages, for which the others called
> get_user_pages(). This takes a reference to the given user pages to let
> kernel to operate directly on the page content. This is usually used for
> preventing swaping out the page contents and doing direct DMA to/from
> userspace.
>
> 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.
>
> The proposed extensions is used by V4L2/VideoBuf2
> (drivers/media/v4l2-core/videobuf2-dma-contig.c), but that is not the
> only place which might benefit from it, like any driver which use DMA to
> userspace with get_user_pages(). This one is provided to demonstrate the
> use case.
>
> I would like to hear some comments on the presented approach. What do
> you think about it? Is there a chance to get such workaround merged at
> some point to mainline?
I'm interested in your idea since it seems that the idea solves my issue:
https://lkml.org/lkml/2012/11/29/69
So I want to apply your idea to a memory hot plug.
Thanks,
Yasuaki Ishimatsu
>
> Best regards
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
> Patch summary:
>
> Marek Szyprowski (5):
> mm: introduce migrate_replace_page() for migrating page to the given
> target
> mm: get_user_pages: use static inline
> mm: get_user_pages: use NON-MOVABLE pages when FOLL_DURABLE flag is
> set
> mm: get_user_pages: migrate out CMA pages when FOLL_DURABLE flag is
> set
> media: vb2: use FOLL_DURABLE and __get_user_pages() to avoid CMA
> migration issues
>
> drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 +-
> include/linux/highmem.h | 12 ++-
> include/linux/migrate.h | 5 +
> include/linux/mm.h | 76 ++++++++++++-
> mm/internal.h | 12 +++
> mm/memory.c | 136 +++++++++++-------------
> mm/migrate.c | 59 ++++++++++
> 7 files changed, 225 insertions(+), 83 deletions(-)
>
next prev parent reply other threads:[~2013-03-06 1:35 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
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 [this message]
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=51369D09.8040103@jp.fujitsu.com \
--to=isimatu.yasuaki@jp.fujitsu.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=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.