On Aug 25, 2006, at 5:48 PM, [EMAIL PROTECTED] wrote:

note2: in page_alloc.c, one of the three clear_page() calls breaks the system
when changed to clear_page_cacheable().

I suspected why this was troubleseme, but I was wrong, can you give us a reason why you think it is?
Off to the code...
Since everything is caches I'll ignore the non-cacheable versions and only consider the cacheable versions.

+static __inline__ void copy_page(void *dp, void *sp)

+/* assumes page, *addr, is cacheable */
+static __inline__ void clear_page_cacheable(void *addr)
EVERYTHING is cacheable.
  +static __inline__ void clear_page(void *addr)
+       unsigned long lines, line_size;
+       line_size = CACHE_LINE_SIZE;
This should really be a function defined in arch/powerpc/powerpc64/ ppc970.c maybe something like cpu_cache_line_size(), or at some point we should prolly have a struct cpu_info that contains all this stuff rather than make a call for this stuff all the time.
Tho I think Hollis and I will have to debate this one :)

+/* assumes destination page, *dp, is cacheable */
+static __inline__ void copy_page_cacheable(void *dp, void *sp)
+static __inline__ void copy_page(void *dp, void *sp)
+       unsigned long dwords, dword_size;
+       dword_size = 8;
+       dwords = (PAGE_SIZE / dword_size) - 1;
+       clear_page_cacheable(dp);

why the clear?
If your intent was to clear the cache line to avoid read-modify- write, then integrating it into the loop would have a much bigger effect.

+       __asm__ __volatile__(
+       "mtctr     %2      # copy_page\n\
+       ld      %2,0(%1)\n\
+       std     %2,0(%0)\n\
+1:     ldu     %2,8(%1)\n\
+       stdu    %2,8(%0)\n\
+       bdnz    1b"
+       : /* no result */
+       : "r" (dp), "r" (sp), "r" (dwords)
Nt 100% sure on this, but since, at the end of your assembler you are changing %0-%2 the should be "=r" in the output area or in the clobber list.
+       : "%ctr", "memory");


Xen-ppc-devel mailing list

Reply via email to