On Thu, May 29, 2008 at 10:25 AM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > On 5/29/08, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> Hi Vegard, I have some questions for you. >> > > [...] > >> Second, your present tried to retain the CR3 value, but change the >> contents of the page table instead....but has problem with >> multiprocessor. >> >> How about the other way round - change the contents of per-CPU CR3, >> which will point to a different pagetable - (subtable). Not sure if >> this is the "per-cpu" pagetable that Ingo is suggesting to you. But >> I am suggesting a very small subtable - only those entries needed are >> constructed. After use it will be switch back to the original CR3. >> Possible? > > Hi, > > Sorry for the short reply but I am short on time :) > > So this is actually a very good idea. I previously disregarded it as > impossible because you can have for example a CMPS instruction that > compares (in fact) TWO memory locations). But it shouldn't be worse > than simply making two entries in that new page table :-) > > For this, we would only need as many pages as we have levels in the > page table, e.g. two or three extra pages per CPU. And we only have to > copy at most two words per level, i.e. at most 6 reads/writes. This > will certainly be a killer if it works. > > (The most overhead I'm guessing will come from reloading the CR3 twice > on each #PF. But then again, it might not be so much compared to what > we already do. I honestly don't know! It's much, much better than > halting all the other CPUs, though!) > > Thanks a lot for this suggestion! I will try to implement the idea and > see if I can find any fatal consequences. Okay, I remembered why this won't work. I just needed to wake up properly. Of course we also need to copy all the page tables for the code itself, the stack, etc. And copying all this for each page fault will also take too much time. So it seems per-cpu page tables will be the only way to go for SMP support. Maybe I will find the time to try this during the summer :-) Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
