On Aug 28, 2006, at 1:10 PM, Hollis Blanchard wrote:

On Mon, 2006-08-28 at 11:58 -0400, Jimi Xenidis wrote:
On Aug 28, 2006, at 11:49 AM, Hollis Blanchard wrote:

On Mon, 2006-08-28 at 11:31 -0400, Jimi Xenidis wrote:
On Aug 28, 2006, at 10:50 AM, Hollis Blanchard wrote:


Also, it looks like you've removed support for mambo_memcpy(). I
don't
use Mambo *ahem* systemsim myself, but that seems worth keeping. I
guess
you could rename the function while you're in there. :)

if we get these down to dcbz's then system performance is fine and am
happy to drop.

I think you're saying that if we have a clear_page() loop that uses
dcbz, systemsim performance is fine. Is that correct?
yes

Is that just because it reduces the number of loops? Using 128 byte
increments instead of 8 would reduce the iterations from 512 to 32.

According the the patch clear_page_cachable() (which we all agreed is just clear_page()) does look only 32 times
systemsym can to dcbz very fast not worth using the callthru.



Is that also the case for copy_page()?

No but it is not called to often, infact not at all AFAICT. I just
removed it and build fine :)
Thats not to say that there aren't any opportunities to use it.

Right. As long as we're changing this code, let's include copy_page().

... which brings us back to the original patch a) removing the call to
mambo_memcpy(), and b) missing dcbtst.

I think we should use the linux copy4kpage() strategy for this.. no sense reinventing the wheel. We should also consider sending a linux patch upstream that has this function use dcbz or find out why they did not.

-JX



_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Reply via email to