This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On 2/22/2012 11:08 AM, Ralph Castain wrote:
> On Feb 22, 2012, at 11:59 AM, Brice Goglin wrote:
>> Le 22/02/2012 17:48, Ralph Castain a écrit :
>>> On Feb 22, 2012, at 9:39 AM, Eugene Loh wrote
>>>> On 2/21/2012 10:31 PM, Eugene Loh wrote:
>>>>> ... "sockets" is unknown and hwloc returns 0 for num_sockets and OMPI pukes on divide by zero. OS info was listed in the original message (below). Might we want to do something else? E.g., assume num_sockets==1 when num_sockets==0 (if you know what I mean)? So, which one (or more) of the following should be fixed?
>>>>> *) on this platform, hwloc finds no socket level
>>>>> *) therefore hwloc returns num_sockets==0 to OMPI
>>>>> *) OMPI divides by 0 and barfs on basically everything
>>>> Okay. So, Brice's other e-mail indicates that the first two are "not really uncommon":
>>>> On 2/22/2012 7:55 AM, Brice Goglin wrote:
>>>>> Anyway, we have seen other systems (mostly non-Linux) where lstopo
>>>>> reports nothing interesting (only one machine object with multiple PU
>>>>> children). So numsockets==0 isn't really uncommon.
>>>> So, it seems to me that OMPI needs to handle the num_sockets==0 case rather than just dividing by num_sockets. This is v1.5 orte_odls_base_open() since r25914.
>>> Unfortunately, just artificially setting the num_sockets to 1 won't solve much - you'll get past that point in the code, but attempts to bind are likely to fail down the road. Fixing it will require some significant effort.
>>> Given we haven't heard reports of this before, I'm not convinced it is a widespread problem.
I assume we don't see the problem as widespread because it was only
introduced into v1.5 in r25914. In my mind, the real question is how
common it is for hwloc to decide numsockets==0. On that one, Brice
asserts it "isn't really uncommon."
>>> For now, let's just use the mca param and see what happens.
>> I am probably missing something but: Why would setting num_sockets to 1
>> work fine as a mca param, while artificially setting it as said above
>> wouldn't ?
> Because the param means that it isn't hardwired into the code base. I want to first verify that artificially forcing num_sockets to 1 doesn't break the code down the road, so the less change to find out, the better.
That sounds a lot different to me than the earlier statement. Thanks
for asking that question, Brice. Anyhow, I tried using "--mca
orte_num_sockets 1" and that seems to allow basic programs to run.