From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28918 invoked by alias); 7 May 2015 19:20:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 28907 invoked by uid 89); 7 May 2015 19:20:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f176.google.com Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com) (209.85.223.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 07 May 2015 19:20:25 +0000 Received: by ieczm2 with SMTP id zm2so47507949iec.2 for ; Thu, 07 May 2015 12:20:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.141.198 with SMTP id rq6mr269321igb.6.1431026423100; Thu, 07 May 2015 12:20:23 -0700 (PDT) Received: by 10.36.38.133 with HTTP; Thu, 7 May 2015 12:20:23 -0700 (PDT) In-Reply-To: <20150507075717.GF1751@tucnak.redhat.com> References: <20150507075717.GF1751@tucnak.redhat.com> Date: Thu, 07 May 2015 19:20:00 -0000 Message-ID: Subject: Re: [rfc] gcc trunk - libgomp thread affinity for freebsd From: Adrian Chadd To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00586.txt.bz2 On 7 May 2015 at 00:57, Jakub Jelinek wrote: > On Wed, May 06, 2015 at 04:29:02PM -0700, Adrian Chadd wrote: >> This patch implements basic top level thread affinity support for >> freebsd. It doesn't yet implement thread affinity support for >> core/socket grouping yet; I'm working on a library to extract that out >> to userland and plan on teaching libgomp about it at a later stage. >> >> https://people.freebsd.org/~adrian/gcc/20150506-gcc-trunk-libgomp-1.diff >> >> I'd appreciate feedback/review. > > In affinity.c, that sounds like way too much code duplication, besides > slightly different includes (but, seems it is only added ones, not removed), > the only differences I see are: > 1) you are assuming HAVE_PTHREAD_AFFINITY_NP is defined, is that really > needed? The configure test should pass and define this macro if you have > it > 2) cpu_set_t vs. cpuset_t > 3) assuming CPU_ALLOC_SIZE is not defined and so aren't CPU_*_S > 4) gomp_cpuset_popcount vs. CPU_COUNT > 5) gomp_affinity_init_level is different > > 1) and 3) can be IMHO kept as is, for 2)/4) you could just add > a short config/freebsd/affinity.c wrapper that includes right headers, > defines a few macros and finally #include "../linux/affinity.c" > For 5), guess that function could be moved into some header > (affinity-init.h) and you could have a different version in config/linux and > config/freebsd. As you add your own proc.c, I guess for 4) also > just defining your own gomp_cpuset_popcount in there would work too. Yes,, a lot of it overlaps with the Linux code. I bet a lot of this stuff can be refactored out into a common affinity routine where the manipulation routines are defined per-platform and we implement the stubs in both linux and freebsd. I'm sure other BSD's could benefit from supporting thread pinning. (And I'm sure non-*NIXes could as well.) I don't mind attempting to take a stab at it, but is it something we could do post initial commit? I'd like to get something useful into the tree so people can immediately benefit from it and then we spin a few cycles together figuring out how to do this in a more platform independent way. Thanks, -adrian