Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 06/10/2009 00:09:16: > > On Tue, 2009-10-06 at 00:00 +0200, Joakim Tjernlund wrote: > > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 05/10/2009 > > 23:37:23: > > > > > > On Mon, 2009-10-05 at 23:25 +0200, Joakim Tjernlund wrote: > > > > > > > > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote on 05/10/2009 > > > > 22:17:04: > > > > > > > > > > On Mon, 2009-10-05 at 14:16 +0200, Joakim Tjernlund wrote: > > > > > > Update the TLB asm to make proper use of _PAGE_DIRY and > > > > > > _PAGE_ACCESSED. > > > > > > Pros: > > > > > > - I/D TLB Miss never needs to write to the linux pte. > > > > > > - _PAGE_ACCESSED is only set on I/D TLB Error fixing accounting > > > > > > - _PAGE_DIRTY is mapped to 0x100, the changed bit, and is set > > > > > > directly > > > > > > when a page has been made dirty. > > > > > > > > > > Not sure here. You seem to still set those from asm. Is that > > > > > necessary ? > > > > > > > > Well, yes. head_32.S also sets ACCESSED and DIRTY from asm so why not > > > > me? > > > > > > Don't look at the hash 32 code :-) > > > > So what to look at then? :) > > head_440.S on a recent 2.6
OK, will look > > > > Most of the time you do anyways since the PTE isn't populated at all. At > > > which point, Linux will populate a PTE with DIRTY and ACCESSED already > > > set. It should be reasonably rare to actually fault because DIRTY and/or > > > ACCESSED are missing. > > > > I tried to unconditionally trap to C in DTLB error but it just hung if I did > > that so the asm has to do something. > > Sure, the question is what and how can we get away without it ? :-) You tell me :) > > > > > > The approach I take on BookE is to simply not set these from asm, > > > > > -and- > > > > > (this is important) not set write permission if dirty is not set in > > > > Did you really mean "if dirty is not" ? I test RW for write permission. > > Dirty is just set when the first write happens after the permission check. > > Sure but if dirty is cleared by the kernel, then you also need to remove > write permission in the TLB or it will miss setting dirty on the next > store to the page. Dirty map to HW changed bit so if kernel clears it, the next store will trap to DTLB error. There I will check RW and clear it again without trapping to C. Is that OK? Not if I read you correcly below .. > > So dirty basically acts as a filter on RW, and accessed as a filter on > valid if you want. > > > > Mostly only !ACCESSED -> no access permitted and !DIRTY -> no store > > > permitted and don't write anything back if !VALID. > > > > That should be !RW and not !DIRTY I hope? Then trap > > first store and set DIRTY (without trapping to C) > > No it's really !(RW _AND_ DIRTY) -> no store permitted, and .. hmm, I don't do that. I should do a if ( store && !(pte & (RW | DIRTY)) goto DSI in DTLB error? > !(PRESENT _AND_ ACCESSED) -> no access permitted. Yes, how about those pinned kernel ptes. Do they have ACCESSED from start? > > Cheers, > Ben. > > > > > > > Cheers, > > > Ben. > > > > > > > Jocke > > > > > > > > > > > > > > Cheers, > > > > > Ben. > > > > > > > > > > > - Proper RO/RW mapping of user space. > > > > > > - Free up 2 SW TLB bits in the linux pte(add back _PAGE_WRITETHRU > > > > > > ?) > > > > > > Cons: > > > > > > - 4 more instructions in I/D TLB Miss, but the since the linux pte > > > > > > is > > > > > > not written anymore, it should still be a win. > > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev