From: Andi Kleen <ak@suse.de>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andi Kleen <ak@suse.de>, Andrew Morton <akpm@zip.com.au>,
linux-kernel@vger.kernel.org,
Manfred Spraul <manfreds@colorfullife.com>
Subject: Re: Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments
Date: Sat, 12 Jan 2002 16:54:43 +0100 [thread overview]
Message-ID: <20020112165443.A13179@wotan.suse.de> (raw)
In-Reply-To: <3C3F3C7F.76CCAF76@colorfullife.com.suse.lists.linux.kernel> <3C3F4FC6.97A6A66D@zip.com.au.suse.lists.linux.kernel> <p73r8ow4dd7.fsf@oldwotan.suse.de> <20020112163332.M1482@inspiron.school.suse.de>
In-Reply-To: <20020112163332.M1482@inspiron.school.suse.de>
On Sat, Jan 12, 2002 at 04:33:32PM +0100, Andrea Arcangeli wrote:
> it doesn't (of course depends "what's the right thing"), and that's why
I think it does. Allocating all possible in future allocated pages
is just not possible for VM_GROWSDOWN, because the stack has really
no suitable limit (other than rlimits, which are far too big to
mlock them)
BTW expand_stack seems to have a small bug: it adds to mm->locked_vm
the complete offset from last vm_start; if it covers more than one page
the locked_vm value will be too large.
> What the current kernel is doing with page faults, is to fault in only
> the touched pages, not the pages in between as well, this isn't a
> security concern because the faulted in pages won't be swapped out, but
> it may matter for some RT app, OTOH the RT apps would better memset the
> whole stack they need before assuming they won't get page faults, first
> of all because of all other kernels out there (this is what I mean with
> a matter of API).
For the stack they can get minor faults anyways when they allocate new
stack space below ESP. There is no good way to fix that from the kernel; the
application has to preallocate its memory on stack. I think it's reasonable
if it does the same for holes on the stack.
-Andi
next prev parent reply other threads:[~2002-01-12 15:55 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 ` Andi Kleen
2002-01-12 1:04 ` Andrew Morton
2002-01-12 15:33 ` Andrea Arcangeli
2002-01-12 15:54 ` Andi Kleen [this message]
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=20020112165443.A13179@wotan.suse.de \
--to=ak@suse.de \
--cc=akpm@zip.com.au \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=manfreds@colorfullife.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®