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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home