Messages in this thread |  | | Date | Tue, 06 May 2003 21:10:24 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [PATCH] kmalloc_percpu |
| |
>>> Same address mapped differently on different cpus is what I thought >>> you meant. It does make sense, and besides, it only really matters >>> when the thing is being switched in, so I think it's not such a big >>> deal. e.g. mark per-thread mm context with the cpu it was prepped for, >>> if they don't match at load-time then reset the kernel pmd's pgd entry >>> in the per-thread pgd at the top level. x86 blows away the TLB at the > > On Wed, May 07, 2003 at 02:56:53PM +1000, Paul Mackerras wrote: >> Having to have a pgdir per thread would be a bit sucky, wouldn't it? > > Not as bad as it initially sounds; on non-PAE i386, it's 4KB and would > hurt. On PAE i386, it's 32B and can be shoehorned, say, in thread_info. > Then the rest is just a per-cpu kernel pmd and properly handling vmalloc > faults (which are already handled properly for non-PAE vmallocspace). > There might be other reasons to do it, like reducing the virtualspace > overhead of the atomic kmap area, but it's not really time yet.
Even if the space isn't a problem, having a full TLB flush on thread context switch sounds sucky. Per-node is sufficient for most things, and is much cheaper (update on cross-node migrate).
M.
- 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/
|  |