From: Pete Zaitcev <zaitcev@redhat.com>
To: riel@redhat.com
Cc: zaitcev@redhat.com, linux-kernel@vger.kernel.org, linux390@de.ibm.com
Subject: gcc-3.2 breaks rmap on s390x
Date: Thu, 3 Apr 2003 13:10:54 -0500 [thread overview]
Message-ID: <20030403131054.B25676@devserv.devel.redhat.com> (raw)
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
next reply other threads:[~2003-04-03 17:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-03 18:10 Pete Zaitcev [this message]
2003-04-03 18:44 ` gcc-3.2 breaks rmap on s390x Rik van Riel
2003-04-03 19:00 ` Davide Libenzi
2003-04-03 19:01 ` Hugh Dickins
2003-04-03 19:30 ` Pete Zaitcev
2003-04-03 19:17 ` Anton Blanchard
-- strict thread matches above, loose matches on Subject: below --
2003-04-03 19:42 Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030403131054.B25676@devserv.devel.redhat.com \
--to=zaitcev@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.