Do we need tlbsx at finish_tlb_load?

A question to Dan and Tom in particular:

At the moment on 4xx, just after finish_tlb_load, which is called by
both the TLB miss handlers, we do a tlbsx to see if an entry for this
virtual address already exists.

Since this code is only called from the TLB miss handler, I can't see
how there could ever be a valid TLB entry present at this point.
There is a comment claiming that this path can be hit under some
circumstances, but it doesn't make sense to me.

Is there any situation where we can reach this point with a valid TLB
entry existing for the faulting address?

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Thu, May 30, 2002 at 06:04:34PM +1000, David Gibson wrote:

A question to Dan and Tom in particular:

At the moment on 4xx, just after finish_tlb_load, which is called by
both the TLB miss handlers, we do a tlbsx to see if an entry for this
virtual address already exists.

Since this code is only called from the TLB miss handler, I can't see
how there could ever be a valid TLB entry present at this point.
There is a comment claiming that this path can be hit under some
circumstances, but it doesn't make sense to me.

Is there any situation where we can reach this point with a valid TLB
entry existing for the faulting address?

Ok, not seeing any replies here.  If no-one speaks up for this tlbsx
in the next couple of days, I'll remove it from 2_4_devel.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

David Gibson wrote:

Ok, not seeing any replies here.  If no-one speaks up for this tlbsx
in the next couple of days, I'll remove it from 2_4_devel.

Some of us (fortunately) have a life outside of kernel hacking, so
it takes time to reply.

An instuction TLB miss will load the TLB with a PTE that indicates it isn't
valid.  A subsequent TLB instruction fault to load the page will cause a
data tlb miss to copy the page, and when you fix up this entry to allow a
write, you don't want to create an alias in the TLB.

If you remove the tlbsx, you can see this happen when init starts and you
dump the TLB after every type of TLB fault while it is starting.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Mon, Jun 03, 2002 at 08:19:32PM -0400, Dan Malek wrote:

David Gibson wrote:

quoted

Ok, not seeing any replies here.  If no-one speaks up for this tlbsx
in the next couple of days, I'll remove it from 2_4_devel.

Some of us (fortunately) have a life outside of kernel hacking, so
it takes time to reply.

An instuction TLB miss will load the TLB with a PTE that indicates it isn't
valid.  A subsequent TLB instruction fault to load the page will cause a
data tlb miss to copy the page, and when you fix up this entry to allow a
write, you don't want to create an alias in the TLB.

I don't follow you.  Either there is a TLB entry for the virtual
address or there isn't.  If there isn't, we'll get an ITLB or DTLB
miss and the tlbsx will always fail.  If there is, we'll get a DSI or
an ISI.  ISI never loads a TLB entry anyway, and DSI does so using a
different code path from the TLB miss handlers which does (and needs
to) do a tlbsx.  The tlbsx at finish_tlb_load is *only* called from
the TLB miss vectors, never from DSI or ISI.

If you remove the tlbsx, you can see this happen when init starts and you
dump the TLB after every type of TLB fault while it is starting.

Well I haven't removed it, but the large page patch also counts the
number of times this tlbsx gets a hit.  I've never seen the number to
be non-zero.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Dan Malek writes:

An instuction TLB miss will load the TLB with a PTE that indicates it isn't
valid.  A subsequent TLB instruction fault to load the page will cause a

If the PTE isn't valid (i.e. the _PAGE_PRESENT bit is 0) we don't put
it into the TLB.  If we did it would be ignored by the hardware and we
would get another TLB miss straight away.  I believe that on 8xx you
actually have two valid bits in each TLB entry, so you can have a TLB
entry that is "valid" but describes a non-present page.  That isn't
the case on 4xx.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Paul Mackerras wrote:

If the PTE isn't valid (i.e. the _PAGE_PRESENT bit is 0) we don't put
it into the TLB.

OK, so remove the tlbsx..........The tlb handler doesn't look like the
one I originally wrote, so whoever made the changes should have understood
and changed everything.  I'm just explaining why it was there in the first
place, maybe it isn't needed anymore.

IMHO, a tlb miss handler design should simply emulate a hardware implementation,
and fetch the PTE entries into the TLB cache as quickly and efficiently as
possible.  You are typically loading valid, ready to use PTEs in a much higher
proportion to invalid ones, and I don't like the normal fast path cluttered
by the overhead of checking the special cases that require more work.


Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Dan Malek writes:

IMHO, a tlb miss handler design should simply emulate a hardware implementation,
and fetch the PTE entries into the TLB cache as quickly and efficiently as
possible.  You are typically loading valid, ready to use PTEs in a much higher
proportion to invalid ones, and I don't like the normal fast path cluttered
by the overhead of checking the special cases that require more work.

Well, simpler is better with a TLB miss handler, for sure.

However, in the context of 4xx, if we load an entry into the TLB with
the valid bit clear, all that will happen is that the cpu will give us
the same TLB miss exception again immediately.  So that doesn't get us
anywhere at all.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Paul Mackerras wrote:

However, in the context of 4xx, if we load an entry into the TLB with
the valid bit clear, all that will happen is that the cpu will give us
the same TLB miss exception again immediately.

Yes, I remember now....thanks for reminding me.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/