From: William Lee Irwin III <wli@holomorphy.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Christoph Hellwig <hch@suse.de>,
"Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
Hugh Dickins <hugh@veritas.com>,
Rik van Riel <riel@conectiva.com.br>,
Dave McCracken <dmccr@us.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Creating a per-task kernel space for kmap, user pagetables, et al
Date: Thu, 21 Mar 2002 15:49:43 -0800 [thread overview]
Message-ID: <20020321234943.GC785@holomorphy.com> (raw)
In-Reply-To: <127930000.1016651345@flay> <20020320212341.M4268@dualathlon.random> <20020320203520.A2003@infradead.org> <20020320223425.P4268@dualathlon.random> <20020320214607.A6363@infradead.org> <20020320230002.A16801@dualathlon.random>
On Wed, Mar 20, 2002 at 11:00:02PM +0100, Andrea Arcangeli wrote:
> Thet's another bit yes, but we'll need 200000 tasks to overflow the
> lowmem (ignoring the fact the lowmem is shared also for the other lowmem
> data structures) and there's the PID limit of 64k tasks. So I don't see
> it as a major thing. Anyways if we really wanted to put the stack [and
> task structure of course] in highmem, we could do that in two additional
> entries after the user stack together with the two entries for the
> pagecache and pagetable persistent kmaps. I think we can officially call
> that area the "userfixmap" or "per-process-fixmap" (no matter if it's in
> user or kernel space). But it is much faster to keep the kernel stack
> always in 4M global tlbs, thus I don't think we need to change that in
> 2.5. (also USB was used to do dma in the kernel stack, not sure if they
> changed it recently)
Another (perhaps obvious) pitfall is stack-allocated storage used for
components of globally-mapped structures. The premier example of this
is probably waitqueues. To keep them working, dynamic allocation of
globally-mapped storage or per-task static allocation thereof is
required as a substitute.
Cheers,
Bill
next prev parent reply other threads:[~2002-03-21 23:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-20 19:09 Creating a per-task kernel space for kmap, user pagetables, et al Martin J. Bligh
2002-03-20 19:36 ` Rik van Riel
2002-03-20 20:26 ` Andrea Arcangeli
2002-03-20 19:45 ` Christoph Hellwig
2002-03-20 23:39 ` Alan Cox
2002-03-21 4:21 ` Itai Nahshon
2002-03-21 13:34 ` Alan Cox
2002-03-21 14:34 ` Martin J. Bligh
2002-03-21 15:38 ` Itai Nahshon
2002-03-20 19:56 ` Hugh Dickins
2002-03-20 20:23 ` Andrea Arcangeli
2002-03-20 20:35 ` Christoph Hellwig
2002-03-20 21:17 ` Hugh Dickins
2002-03-20 21:38 ` Andrea Arcangeli
2002-03-20 21:34 ` Andrea Arcangeli
2002-03-20 21:46 ` Christoph Hellwig
2002-03-20 22:00 ` Andrea Arcangeli
2002-03-21 19:54 ` Greg KH
2002-03-21 23:29 ` Andrea Arcangeli
2002-03-21 23:49 ` William Lee Irwin III [this message]
2002-03-22 1:20 ` Andrea Arcangeli
2002-03-20 22:10 ` Martin J. Bligh
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=20020321234943.GC785@holomorphy.com \
--to=wli@holomorphy.com \
--cc=Martin.Bligh@us.ibm.com \
--cc=andrea@suse.de \
--cc=dmccr@us.ibm.com \
--cc=hch@suse.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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.