On Aug 25, 2006, at 5:48 PM, poff@xxxxxxxxxxxxxx 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)
[ignore]
+/* 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");
+}
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
| 
Home