From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9174 invoked by alias); 30 Jul 2010 14:00:31 -0000 Received: (qmail 8705 invoked by uid 48); 30 Jul 2010 14:00:14 -0000 Date: Fri, 30 Jul 2010 14:00:00 -0000 Message-ID: <20100730140014.8704.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgomp/43706] scheduling two threads on one core leads to starvation In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "johnfb at mail dot utexas dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg03313.txt.bz2 ------- Comment #15 from johnfb at mail dot utexas dot edu 2010-07-30 14:00 ------- We have also had some trouble with this issue. We found that in general if we where running on a machine with hardware threads (i.e., Intel's Hyper-Threading) then performance was poor. Most of our runs where on a machine with a Intel Xeon L5530 running RHEL 5. Profiling showed that our program was spending 50% of its time inside libgomp. Setting either GOMP_SPINCOUNT or OMP_WAIT_POLICY as discussed in this thread increased performance greatly. Experiments with disabling and enabling cores with default OMP settings showed that when the Hyper-Thread cores come on performance dipped below what we got when we had only one core enabled on some runs. A little thought as to how hardware threads are implemented makes it obvious why spinning for more than a few cycles will cause performance problems. If one hardware threads spins then all other threads on that core may be starved as resources are shared between cores. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706