lkml.org 
[lkml]   [2013]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages()
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




\
 
 \ /
  Last update: 2013-03-05 15:21    [W:0.255 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site