Why not make /tmp-public and /tmp-private?
Leave /tmp alone. Have all new branches made in one of the two new
directories, and as /tmp branches are slowly whacked, we can
(eventually) get rid of /tmp.
Tim
Jeff Squyres (jsquyres) wrote:
I thought about both of those (/tmp/private and /tmp/pub
On Aug 31, 2007, at 8:14 AM, Tim Prins wrote:
Why not make /tmp-public and /tmp-private?
Leave /tmp alone. Have all new branches made in one of the two new
directories, and as /tmp branches are slowly whacked, we can
(eventually) get rid of /tmp.
I'm fine with that. If no one else objects, l
On 8/31/07 6:18 AM, "Jeff Squyres" wrote:
> On Aug 31, 2007, at 8:14 AM, Tim Prins wrote:
>
>> Why not make /tmp-public and /tmp-private?
>>
>> Leave /tmp alone. Have all new branches made in one of the two new
>> directories, and as /tmp branches are slowly whacked, we can
>> (eventually) g
That's fine, too. I don't really care -- /public already exists. We
can simply rename it to /tmp-public.
On Aug 31, 2007, at 8:52 AM, Ralph Castain wrote:
Why not make /tmp-public and /tmp-private?
Leave /tmp alone. Have all new branches made in one of the two new
directories, and as /tmp
Jeff Squyres wrote:
That's fine, too. I don't really care -- /public already exists. We
can simply rename it to /tmp-public.
Let's do that. It should (more or less) address all concerns that have
been voiced.
Tim
On Aug 31, 2007, at 8:52 AM, Ralph Castain wrote:
Why not make /tmp-pu
Done. Public temp branches are now [strongly] encouraged to use /tmp-
public.
https://svn.open-mpi.org/trac/ompi/changeset/16030
On Aug 31, 2007, at 8:57 AM, Tim Prins wrote:
Jeff Squyres wrote:
That's fine, too. I don't really care -- /public already exists. We
can simply rename it t
Ok, I have an update to this issue. I believe there is an
implementation difference of sched_yield between Linux and Solaris. If
I change the sched_yield in opal_progress to be a usleep(500) then my
program completes quite quickly. I have sent a few questions to a
Solaris engineer and hopefu
Terry,
Are you testing on Linux? If so, which kernel?
See the patch to iperf to handle kernel 2.6.21 and the issue that
they had with usleep(0):
http://dast.nlanr.net/Projects/Iperf2.0/patch-iperf-linux-2.6.21.txt
Scott
On Aug 31, 2007, at 1:36 PM, Terry D. Dontje wrote:
Ok, I have an up
Scott Atchley wrote:
Terry,
Are you testing on Linux? If so, which kernel?
No, I am running into issues on Solaris but Ollie's run of the test code
on Linux seems to work fine.
--td
See the patch to iperf to handle kernel 2.6.21 and the issue that
they had with usleep(0):
http://das
