All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michel Lespinasse <walken@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hugh Dickins <hugh.dickins@tiscali.co.uk>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Nick Piggin <npiggin@kernel.dk>, Rik van Riel <riel@redhat.com>
Subject: Re: [RFC] mlock: release mmap_sem every 256 faulted pages
Date: Mon, 22 Nov 2010 21:57:46 -0800	[thread overview]
Message-ID: <20101122215746.e847742d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101123050052.GA24039@google.com>

On Mon, 22 Nov 2010 21:00:52 -0800 Michel Lespinasse <walken@google.com> wrote:

> Hi,
> 
> I'd like to sollicit comments on this proposal:
> 
> Currently mlock() holds mmap_sem in exclusive mode while the pages get
> faulted in. In the case of a large mlock, this can potentially take a
> very long time.

A more compelling description of why this problem needs addressing
would help things along.

> +		/*
> +		 * Limit batch size to 256 pages in order to reduce
> +		 * mmap_sem hold time.
> +		 */
> +		nfault = nstart + 256 * PAGE_SIZE;

It would be nicer if there was an rwsem API to ask if anyone is
currently blocked in down_read() or down_write().  That wouldn't be too
hard to do.  It wouldn't detect people polling down_read_trylock() or
down_write_trylock() though.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Michel Lespinasse <walken@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hugh Dickins <hugh.dickins@tiscali.co.uk>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Nick Piggin <npiggin@kernel.dk>, Rik van Riel <riel@redhat.com>
Subject: Re: [RFC] mlock: release mmap_sem every 256 faulted pages
Date: Mon, 22 Nov 2010 21:57:46 -0800	[thread overview]
Message-ID: <20101122215746.e847742d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101123050052.GA24039@google.com>

On Mon, 22 Nov 2010 21:00:52 -0800 Michel Lespinasse <walken@google.com> wrote:

> Hi,
> 
> I'd like to sollicit comments on this proposal:
> 
> Currently mlock() holds mmap_sem in exclusive mode while the pages get
> faulted in. In the case of a large mlock, this can potentially take a
> very long time.

A more compelling description of why this problem needs addressing
would help things along.

> +		/*
> +		 * Limit batch size to 256 pages in order to reduce
> +		 * mmap_sem hold time.
> +		 */
> +		nfault = nstart + 256 * PAGE_SIZE;

It would be nicer if there was an rwsem API to ask if anyone is
currently blocked in down_read() or down_write().  That wouldn't be too
hard to do.  It wouldn't detect people polling down_read_trylock() or
down_write_trylock() though.

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-11-23  6:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-23  5:00 [RFC] mlock: release mmap_sem every 256 faulted pages Michel Lespinasse
2010-11-23  5:00 ` Michel Lespinasse
2010-11-23  5:57 ` Andrew Morton [this message]
2010-11-23  5:57   ` Andrew Morton
2010-11-23  7:49   ` KOSAKI Motohiro
2010-11-23  7:49     ` KOSAKI Motohiro
2010-11-23 20:55   ` Michel Lespinasse
2010-11-23 20:55     ` Michel Lespinasse
2010-11-23 23:57     ` KOSAKI Motohiro
2010-11-23 23:57       ` KOSAKI Motohiro
2010-12-01  0:14 ` KOSAKI Motohiro
2010-12-01  0:14   ` KOSAKI Motohiro
2010-12-01  4:42 ` KOSAKI Motohiro
2010-12-01  4:42   ` KOSAKI Motohiro

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=20101122215746.e847742d.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@kernel.dk \
    --cc=riel@redhat.com \
    --cc=walken@google.com \
    /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.