Messages in this thread | | | Date | Fri, 22 Mar 2002 02:20:56 +0100 | From | Andrea Arcangeli <> | Subject | Re: Creating a per-task kernel space for kmap, user pagetables, et al |
| |
On Thu, Mar 21, 2002 at 03:49:43PM -0800, William Lee Irwin III wrote: > 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.
Agreed, good point (in theory task struct could go there, I'm not suggesting that of course, but stack has to remain visible to all MM for such reason).
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |