[PATCH] [2.4] [RHEL] Backport of benh's PTE mgmt changes

[olof at austin.ibm.com]

On Wed, 7 Jan 2004, Benjamin Herrenschmidt wrote:

> On Wed, 2004-01-07 at 11:01, olof at austin.ibm.com wrote:
> > Below is a 2.4 backport of parts of benh's 2.6 pte_free rewrite. It's
> > different in a few ways:
> >
> > 1. 2.4 has no RCU. Instead I just send a syncronous IPI to all processors.
> > Since the IPI won't be delivered until a processor is out of hash_page, it
> > can be used as a barrier between new and old traversals.
>
> But is also quite expensive....

I'll try to see how visible is with workloads. I'm not sure how
syncronization could be acheived without either RCU or IPI support, so
hopefully it won't be a big hit.

> I moved bits around on 2.6, basically, _PAGE_FILE can be moved as it's
> only used when !_PAGE_PRESENT, to make room.

Yeah, I wanted to keep changes at a minimum here so I just grabbed the
first available.

> Heh, so you kept the C version stuffing the asm atomic stuff
> in :) Why note... well, it's definitely less invasive that what
> I did in 2.6 but also less performant since I optimized the
> branches to the ppc_md. hooks. That's probably ok for 2.4 though.

Exactly. I quite honestly had no desire to rewrite the 2.4 function in
asm. Performance should only be worse compared to 2.6, it doesn't do much
harm to 2.4. In other words: I brought over the functionality, but not the
additional performance enhancements. :)

> > +	/* Clear _PAGE_BUSY flag atomically. */
> > +	__asm__ __volatile__ ("
> > +	1:	ldarx	%0,0,%2\n
> > +		andc.	%0,%0,%1\n
> > +		stdcx.	%0,0,%2\n
> > +		bne-	1b\n"
> > +	: "=r" (new_pte)
> > +        : "r" (tmp), "r" (ptep)
> > +        : "cc", "memory");
>
> I'm not sure we need to clear _PAGE_BUSY atomically.... I definitely
> don't in 2.6... But we need to make sure this clear happens after
> anything that was done previously.

You're right. Easy to change.

> The rest is a bit scary but it's 2.4 so... :) I suppose it should
> work though I would have to spend more time looking at the code path
> in details.

Yeah, I wanted to backport the bug/design fix with as little disturbance
to the rest as possible. I'll run some comparison benchmarks to see how
much the added IPI hurts.


-Olof


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