[rfc] gcc trunk - libgomp thread affinity for freebsd

[rfc] gcc trunk - libgomp thread affinity for freebsd

[Adrian Chadd]

Hi,

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.

Thanks!


-adrian

Re: [rfc] gcc trunk - libgomp thread affinity for freebsd

[Jakub Jelinek]

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.

	Jakub

Re: [rfc] gcc trunk - libgomp thread affinity for freebsd

[Adrian Chadd]

On 7 May 2015 at 00:57, Jakub Jelinek <jakub@redhat.com> 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