All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments
Date: Fri, 11 Jan 2002 17:04:37 -0800	[thread overview]
Message-ID: <3C3F8BA5.8B793441@zip.com.au> (raw)
In-Reply-To: <3C3F3C7F.76CCAF76@colorfullife.com.suse.lists.linux.kernel> <3C3F4FC6.97A6A66D@zip.com.au.suse.lists.linux.kernel>, Andrew Morton's message of "11 Jan 2002 21:59:44 +0100" <p73r8ow4dd7.fsf@oldwotan.suse.de>

Andi Kleen wrote:
> 
> Andrew Morton <akpm@zip.com.au> writes:
> 
> > So in this case, the behaviour I would prefer is MCL_FUTURE for
> > all vma's *except* the stack.   Stack pages should be locked
> > only when they are faulted in.   Hard call.
> 
> There is just one problem: linuxthread stacks are just ordinary mappings
> and they are in no way special to the kernel; they aren't VM_GROWSDOWN.
> You would need to add a way to the kernel first to tag the linux thread
> stacks in a way that is recognizable to mlockall and then do that
> from linuxthreads.
> 
> I think for the normal stack - real VM_GROWSDOWN segments - mlockall
> already does the right thing.

hmm.. So I wonder what changed between 2.4.7 and 2.4.15 which unbroke
MCL_FUTURE.

I suspect we can fix the problem by running mlockall(MCL_FUTURE)
and then an explicit munlock() of the stack area.

-

  reply	other threads:[~2002-01-12  1:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3C3F3C7F.76CCAF76@colorfullife.com.suse.lists.linux.kernel>
     [not found] ` <3C3F4FC6.97A6A66D@zip.com.au.suse.lists.linux.kernel>
2002-01-12  0:33   ` Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments Andi Kleen
2002-01-12  1:04     ` Andrew Morton [this message]
2002-01-12 15:33     ` Andrea Arcangeli
2002-01-12 15:54       ` Andi Kleen
2002-01-12 16:07         ` Manfred Spraul
2002-01-12 16:17           ` Andrea Arcangeli
2002-01-12 16:14         ` Andrea Arcangeli
2002-01-11 19:26 Manfred Spraul
2002-01-11 20:49 ` Andrew Morton
2002-01-11 23:45   ` Richard Gooch

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=3C3F8BA5.8B793441@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.