Hi, Rik:
the following patch seems to fix my rmap problems on s390x.
--- linux-2.4.20-2.1.24.z1/include/linux/mm.h 2003-03-27 21:30:09.000000000 -0500
+++ linux-2.4.20-2.1.24.z2/include/linux/mm.h 2003-04-02 20:26:11.000000000 -0500
@@ -376,8 +376,10 @@
*/
#ifdef CONFIG_SMP
while (test_and_set_bit(PG_chainlock, &page->flags)) {
- while (test_bit(PG_chainlock, &page->flags))
+ while (test_bit(PG_chainlock, &page->flags)) {
cpu_relax();
+ barrier();
+ }
}
#endif
}
The failure happens in page_remove_rmap. It runs like so:
if (!page_mapped(page)) // (page->pte.direct!=0)
return; /* remap_page_range() from a driver? */
pte_chain_lock(page);
if (PageDirect(page)) {
if (page->pte.direct == pte_paddr) {
The pte_chain_lock loop is in the patch above.
The compiler loads page->pte.direct into a register when
page_mapped() is tested, and uses it in if statement
across pte_chain_lock().
Andrew Morton observed that bitops on s390(x) do not clobber
memory. I saw it too, but I thought it was legal. A bitop
changes a word in a specific location. I think it just does
not sound right to trash an optimization because of that.
As an example, sparc(32) has a mix of bitops implemented in C
and bitops implemented in assembly. C bitops do not clobber
memory wholesale. Of asm bitops, only test_and_set_bit
clobbers memory (I have to ask Dave why).
Cheers,
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:20 EST