lkml.org 
[lkml]   [2009]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/4] mm: m(un)lock avoid ZERO_PAGE
Date
> I'm still reluctant to clutter __get_user_pages() with another flag,
> just to avoid touching ZERO_PAGE count in mlock(); though we can add
> that later if it shows up as an issue in practice.
>
> But when mlocking, we can test page->mapping slightly earlier, to avoid
> the potentially bouncy rescheduling of lock_page on ZERO_PAGE - mlock
> didn't lock_page in olden ZERO_PAGE days, so we might have regressed.
>
> And when munlocking, it turns out that FOLL_DUMP coincidentally does
> what's needed to avoid all updates to ZERO_PAGE, so use that here also.
> Plus add comment suggested by KAMEZAWA Hiroyuki.
>
> Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
> ---
>
> mm/mlock.c | 49 ++++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 36 insertions(+), 13 deletions(-)
>
> --- mm0/mm/mlock.c 2009-09-14 16:34:37.000000000 +0100
> +++ mm1/mm/mlock.c 2009-09-15 17:32:03.000000000 +0100
> @@ -198,17 +198,26 @@ static long __mlock_vma_pages_range(stru
> for (i = 0; i < ret; i++) {
> struct page *page = pages[i];
>
> - lock_page(page);
> - /*
> - * Because we lock page here and migration is blocked
> - * by the elevated reference, we need only check for
> - * file-cache page truncation. This page->mapping
> - * check also neatly skips over the ZERO_PAGE(),
> - * though if that's common we'd prefer not to lock it.
> - */
> - if (page->mapping)
> - mlock_vma_page(page);
> - unlock_page(page);
> + if (page->mapping) {
> + /*
> + * That preliminary check is mainly to avoid
> + * the pointless overhead of lock_page on the
> + * ZERO_PAGE: which might bounce very badly if
> + * there is contention. However, we're still
> + * dirtying its cacheline with get/put_page:
> + * we'll add another __get_user_pages flag to
> + * avoid it if that case turns out to matter.
> + */
> + lock_page(page);
> + /*
> + * Because we lock page here and migration is
> + * blocked by the elevated reference, we need
> + * only check for file-cache page truncation.
> + */
> + if (page->mapping)
> + mlock_vma_page(page);
> + unlock_page(page);
> + }
> put_page(page); /* ref from get_user_pages() */
> }

Yes, I have similar patch :-)
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>






\
 
 \ /
  Last update: 2009-09-16 02:11    [W:0.432 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site