linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>,
	linux-mm@kvack.org, nickpiggin@yahoo.com.au, akpm@osdl.org
Subject: Re: page migration: Fail with error if swap not setup
Date: Wed, 15 Mar 2006 17:06:33 -0600	[thread overview]
Message-ID: <20060315230633.GA14825@dmt.cnet> (raw)
In-Reply-To: <Pine.LNX.4.64.0603151059080.27630@schroedinger.engr.sgi.com>

On Wed, Mar 15, 2006 at 11:00:31AM -0800, Christoph Lameter wrote:
> On Wed, 15 Mar 2006, Marcelo Tosatti wrote:
> 
> > > That does not answer the question if VM_LOCKED pages should be 
> > > migratable. We all agree that they should not show up on swap.
> > 
> > I guess you missed the first part of the man page:
> > 
> > All pages which contain a part of the specified memory range are
> > guaranteed be resident in RAM when the mlock system call returns
> > successfully and they are guaranteed to stay in RAM until the pages are
> > unlocked by munlock or munlockall, until the pages are unmapped via
> > munmap, or until the process terminates or starts another program with
> > exec. Child processes do not inherit page locks across a fork.
> > 
> > That is, mlock() only guarantees that pages are kept in RAM and not
> > swapped. It does seem to refer to physical placing of pages.
> 
> If VM_LOCKED is not pinning memory then how does one pin memory? There are 
> likely applications / drivers that require memory not to move. Increase 
> pagecount?

Err, I meant that mlock() does _not_ refer to physical placing of pages, 
it only refers to guaranteed availability of page in RAM (as can be read
in the man page).

Now drivers using VM_LOCKED is another history... 

In the end my comments haven't been useful at all, oh well.

--
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>

      reply	other threads:[~2006-03-15 23:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-15  3:05 Christoph Lameter
2006-03-15  3:24 ` Andrew Morton
2006-03-15  3:49   ` Christoph Lameter
2006-03-15  3:52     ` Andrew Morton
2006-03-15  3:59       ` Christoph Lameter
2006-03-15 12:49         ` Nick Piggin
2006-03-15 16:35           ` Christoph Lameter
2006-03-15  3:53   ` Christoph Lameter
2006-03-15 14:47 ` Lee Schermerhorn
2006-03-15 17:11   ` Christoph Lameter
2006-03-15 20:47     ` Marcelo Tosatti
2006-03-15 18:08       ` Christoph Lameter
2006-03-15 21:39         ` Marcelo Tosatti
2006-03-15 19:00           ` Christoph Lameter
2006-03-15 23:06             ` Marcelo Tosatti [this message]

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=20060315230633.GA14825@dmt.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox