From: Marcelo Tosatti <[email protected]>
Date: Sun, 26 Jun 2005 16:09:44 -0300
> Thats a very interesting idea, will probably optimize performance in
> general ("why did nobody thought of it before?" kind).
>
> The increase in TLB miss handler size might be offset by the reduced
> kernel misses...
>
> Dan, what do you think?
I doubt it, it cost a single comparison on sparc64 to implement this.
Basically, the TLB miss handler for data accesses on sparc64 looks
like the following.
Load the miss information:
ldxa [%g1 + %g1] ASI_DMMU, %g4 ! Get TAG_ACCESS
If "TAG_CONTEXT_BITS" is zero, it's for the kernel:
andcc %g4, TAG_CONTEXT_BITS, %g0 ! From Nucleus?
be,pn %xcc, 3f ! Yep, special processing
...
If the virtual address has the top-most bit set (and thus it's
"negative"), then it's in the physical memory direct mapping
area. The trap handler register %g2 is preloaded with a fixed
value, that when XOR'd with the fault address information
produces a suitable PTE for loading right into the TLB. This
PTE uses 4MB pages.
3: brlz,pt %g4, 9b ! Kernel virtual map?
xor %g2, %g4, %g5 ! Finish bit twiddles
...
Store the calculated TLB entry and return from the trap.
9: stxa %g5, [%g0] ASI_DTLB_DATA_IN ! Reload TLB
retry ! Trap return
So that's 7 instructions, 2 instruction cache lines, with no main
memory accesses. Surely the PPC folks can do something similar. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
