>>> 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/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:30 EST