Re: [XenPPC] PATCH: Inline assembler for clear_page() and copy_page()

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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