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
