All of lore.kernel.org
 help / color / mirror / Atom feed
From: John David Anglin <dave.anglin@bell.net>
To: linux-parisc <linux-parisc@vger.kernel.org>
Subject: [PATCH, PA-RISC] Fix SMP cache related HPMCs running libgomp testsuite
Date: Sun, 31 Jul 2011 18:11:43 -0400	[thread overview]
Message-ID: <BLU0-SMTP33BC220C6C43A14F8BF18697390@phx.gbl> (raw)

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

After a considerable amount of testing, I have found that the HPMCs  
that I have been seeing
in the GCC libgomp testsuite are caused by the implementation of  
flush_user_dcache_range.
The current implementation doesn't flush all aliases (e.g., kernel)  
and this leads to cache corruption.
As with flush_cache_mm, we need to either whack the entire cache, or  
do something similar to that
in flush_dcache_page.

The for-[1-8].C tests are the principle problem.  They turn "for  
loops" into a large number of
parallel threads.

I was hoping someone else would have solved this problem, but arm, for  
example, appears to
flush the entire cache on vipt architectures.

The problem with the attached patch is that flushing the entire data  
cache on the rp3440 is
incredibly slow (0x40000 iterations).  I have a patch to unroll the  
loops in flush_instruction_cache_local
and flush_data_cache_local, but still they are still slow.

We are probably missing opportunities to skip flushing the instruction  
cache, but still the data
cache flush will be slow.

What I think needs to be done is to determine the ptep pointer for the  
starting and ending addresses
when the context is current.  From this, we can get the page pointer.   
Then, we may be able to
call flush_dcache_page.  Currently, the only page table lookup that I  
see is in entry.S.

Maybe there is a simpler method?  For example, is there a way to force  
the kernel to use
flush_cache_page.

I'm not sure the change is needed on machines that support non  
equivalent aliases.

Dave



[-- Attachment #2: cache.c.d.1.txt --]
[-- Type: text/plain, Size: 495 bytes --]

diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 83335f3..532e3bf 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -472,10 +472,14 @@ void flush_cache_mm(struct mm_struct *mm)
 void
 flush_user_dcache_range(unsigned long start, unsigned long end)
 {
+#ifdef CONFIG_SMP
+	flush_data_cache();
+#else
 	if ((end - start) < parisc_cache_flush_threshold)
 		flush_user_dcache_range_asm(start,end);
 	else
 		flush_data_cache();
+#endif
 }
 
 void

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


--
John David Anglin	dave.anglin@bell.net



                 reply	other threads:[~2011-07-31 22:11 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=BLU0-SMTP33BC220C6C43A14F8BF18697390@phx.gbl \
    --to=dave.anglin@bell.net \
    --cc=linux-parisc@vger.kernel.org \
    /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.