linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Christoph Lameter <clameter@sgi.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Track mlock()ed pages
Date: Sat, 27 Jan 2007 17:36:01 -0500	[thread overview]
Message-ID: <45BBD3D1.60605@redhat.com> (raw)
In-Reply-To: <20070127143013.e2c839c0.akpm@osdl.org>

Andrew Morton wrote:
> On Sat, 27 Jan 2007 17:19:21 -0500
> Rik van Riel <riel@redhat.com> wrote:
> 
>> Andrew Morton wrote:
>>
>>> Of course it would.  But how do you know it is "too expensive"?  We "scan
>>> all the vmas mapping a page" as a matter of course in the page scanner -
>>> millions of times a minute.  If that's "too expensive" then ouch.
>> We can do it lazily.
>>
>> At mlock time, move pages onto the mlocked list, unless they
>> are there already.
> 
> Needs another page flag to determine what list the page is on (eek).
> 
>> On munlock, move pages to the active list.
> 
> We'd need to determine whether some other vma has mlocked the page too. 
> That's either the page_struct refcount or the vma walk.  The latter is
> equivalent to what I'm suggesting.

It doesn't have to be 100% accurate.  The pages that are mapped
both mlocked and non-mlocked will probably be only shared
libraries.

>>  For mlock-only
>> memory (shared memory segments?) we could add a simple check
>> to see if the next process on the list has the page mlocked,
>> checking only that one.

As long as we get it right for the large objects, it should be
fine.

> I'm still not sure what problem we're trying to solve here.
> 
> Knowing how many mlocked pages there are in a zone doesn't sound terribly
> interesting and I don't recall ever wanting to know that.
> 
> Being able to keep mlocked pages off the LRU altogether sounds more useful.

> It's all rather a tight corner case - people don't use mlock much.

Just because it's not common does not mean you can just ignore
it and hope Linux doesn't unexpectedly fall over.

One thing that knowing the amount of mlocked data in each zone
(and node) would allow us to do is spread the mlocked memory
around a little better at allocation time.  This could prevent
some of the "I started a 6GB Oracle on my 8GB system and it
immediately fell over" bugs.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

--
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:[~2007-01-27 22:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-26  5:43 [RFC] Track mlock()ed pages Christoph Lameter
2007-01-26  6:30 ` Nick Piggin
2007-01-26  6:36   ` Christoph Lameter
2007-01-26 11:13     ` Andrew Morton
2007-01-26 12:00       ` Nick Piggin
2007-01-26 15:44       ` Christoph Lameter
2007-01-26 18:10         ` Andrew Morton
2007-01-26 18:21           ` KAMEZAWA Hiroyuki
2007-01-26 18:23           ` Christoph Lameter
2007-01-26 18:42             ` Andrew Morton
2007-01-27 22:19               ` Rik van Riel
2007-01-27 22:30                 ` Andrew Morton
2007-01-27 22:36                   ` Rik van Riel [this message]
2007-01-26 11:46     ` Nick Piggin

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=45BBD3D1.60605@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).