From: Andrea Arcangeli <andrea@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: schwidefsky@de.ibm.com, mingo@chiara.elte.hu,
linux-kernel@vger.kernel.org
Subject: Re: Memory management bug
Date: Thu, 16 Nov 2000 18:45:12 +0100 [thread overview]
Message-ID: <20001116184512.A6622@athlon.random> (raw)
In-Reply-To: <C1256999.005B8F06.00@d12mta07.de.ibm.com> <Pine.LNX.4.10.10011160856010.2184-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.10.10011160856010.2184-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Thu, Nov 16, 2000 at 09:01:07AM -0800
On Thu, Nov 16, 2000 at 09:01:07AM -0800, Linus Torvalds wrote:
> "Linux pages" be _two_ hardware pages, and make a Linux pte contain two
If they absolutely needs 4 pages for pmd pagetables due hardware constraints
I'd recommend to use _four_ hardware pages for each softpage, not two.
The issue is that failing allocation at task creation (due 8k [or more] kernel
stack) is trivial to handle, just have the syscall returning -ENOMEM and
userspace will handle the allocation faliure gracefully. Also the parent
of the servers will never fail that allocation after it's up and running
(and it can try to fork childs later on).
Failing allocation of a pagetable in some case can be solved only looping
(deadlock prone) or killing the task hard without giving a chance to userspace
to trap the fault (even SIGKILL signal handler may need that pmd pagetable to
run). So being guaranteed to be able to allocate pagetables unless
the machine is truly out of memory is quite necessary "feature" IMHO.
We faced similar issues while thinking at possible ways for x86-64 pagetables,
and we preferred not having to depend on the softpagesize framework in 2.4.x
because it's very intrusive.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-16 18:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-16 16:12 Memory management bug schwidefsky
2000-11-16 17:01 ` Linus Torvalds
2000-11-16 17:45 ` Andrea Arcangeli [this message]
2000-11-16 18:07 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2000-11-21 19:55 schwidefsky
2000-11-17 16:35 schwidefsky
2000-11-17 16:42 ` Linus Torvalds
2000-11-17 18:11 ` Andrea Arcangeli
2000-11-17 19:15 ` Rik van Riel
2000-11-17 10:41 schwidefsky
2000-11-17 15:44 ` Andrea Arcangeli
2000-11-17 19:12 ` Rik van Riel
2000-11-15 13:24 schwidefsky
2000-11-15 12:39 schwidefsky
2000-11-15 13:19 ` Andi Kleen
2000-11-15 16:45 ` Linus Torvalds
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=20001116184512.A6622@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@chiara.elte.hu \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@transmeta.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