On Wed, May 07, 2008 at 01:53:26PM +0200, Richard Zidlicky wrote:
For the multi-CPU case I think it is difficult to avoid a special per CPU page holding the current TLS pointer. Am I missing something?
I have to admit I didn't consider true SMP. I suppose it is best if we do allow for that in the design even if the current kernel doesn't really have the support to do SMP on m68k.
This page could in principle be shared by all processes per CPU so it is mostly irrelevant whether it can be swapped out. Either way it seems to involve some interesting VM/MM magic. I wonder if the TLS pointer is the only thing that would be variable between processes?
I'm not familiar enough with the low level m68k mm code to be sure, but could we lazily populate the mmu entry for these pages and only make sure they are accurate after a reference? This relies on it being very easy to invalidate mappings during a context switch while not always putting back all the previous mappings for the process being woken up. If that is the case, we could just check on the page fault and update it if needed. We could keep track in the kernel of which thread is really setup in the page. I know something similar is used for FPU state saving on some architectures.
However the more interesting question is how to update this special page, if it is indeed the way to go. Doing it on every context switch would make every context switch a few insns slower for all processes whereas I do expect the TLS functionality to be used rarely. Has anyone a guess how frequent that would be? Last time I tried to benchmark it we had around 250 cycles per process switch on a 68060.. I hope thread switch would be even slightly faster so a few instructions can matter.
I think we have to do something during context switch just to prevent the possibility of leaking information and allowing interference as mentioned in another message in the thread.
Not sure what the VDSO approach would be but it seems to involve either some MM tricks or some updating on context switch so in principle there would still be some cost on every context switch??
I think the only mm tricks in the VDSO on ppc are the adding of it to the process memory maps during exec and being careful about setting the page flags to make sure no process can corrupt it. It's really no different than a normal file-backed DSO other than that there isn't anything backing it so it has to stay resident all the time. I will try to find some time to look at the way we setup the mmu during context switch to see if I can get a feel for what is practical. Brad Boyer flar@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
