From patchwork Sun Jul 31 22:11:43 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John David Anglin X-Patchwork-Id: 1024762 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p6VMBSlU003770 for ; Sun, 31 Jul 2011 22:12:02 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752928Ab1GaWMB (ORCPT ); Sun, 31 Jul 2011 18:12:01 -0400 Received: from blu0-omc4-s4.blu0.hotmail.com ([65.55.111.143]:9843 "EHLO blu0-omc4-s4.blu0.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752907Ab1GaWMB (ORCPT ); Sun, 31 Jul 2011 18:12:01 -0400 Received: from BLU0-SMTP33 ([65.55.111.137]) by blu0-omc4-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 31 Jul 2011 15:12:00 -0700 X-Originating-IP: [69.158.173.138] X-Originating-Email: [dave.anglin@bell.net] Message-ID: Received: from [192.168.2.10] ([69.158.173.138]) by BLU0-SMTP33.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 31 Jul 2011 15:11:59 -0700 From: John David Anglin To: linux-parisc Subject: [PATCH, PA-RISC] Fix SMP cache related HPMCs running libgomp testsuite MIME-Version: 1.0 (Apple Message framework v936) Date: Sun, 31 Jul 2011 18:11:43 -0400 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 Jul 2011 22:12:00.0055 (UTC) FILETIME=[DE6E9C70:01CC4FCE] Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Sun, 31 Jul 2011 22:12:02 +0000 (UTC) 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 --- John David Anglin dave.anglin@bell.net 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