Hello,
the 'make dist[clean]' problem should be fixed now. To avoid that Make
enters a 'ompi/contrib'-directory
of a disabled contributed software the Makefile variable
OMPI_CONTRIB_DIST_SUBDIRS must not be set.
I've tested this fix as follows:
1. configure --enable-contrib-no-build=vt
make
Ralph,
could this mechanism be used also to exclude a node, indicating to never
run a job there? Here is the problem that I face quite often: students
working on the homework forget to allocate a partition on the cluster,
and just type mpirun. Because of that, all jobs end up running on the
WHAT: Removal of orte_proc_table
WHY: It is the last 'orte' class, its implementation is an abstraction
violation since it assumes certain things about how the opal_hash_table
is implemented, and it is not much code to remove it.
WHERE: This will necessitate minor changes in:
btl: tcp, sc
Ralph,
On Monday 03 March 2008 17:06, r...@osl.iu.edu wrote:
> Author: rhc
> Date: 2008-03-03 11:06:47 EST (Mon, 03 Mar 2008)
> New Revision: 17681
> URL: https://svn.open-mpi.org/trac/ompi/changeset/17681
>
> Log:
> Cleanup an attribute warning - not sure which one to set or where it should
> go,
The topic of the "early completion" behavior in OB1 for IB
optimizations has come up several times in the v1.2 series (it causes
problems in some scenarios).
- leave the default the way it is now (early completions enabled)
- add an MCA parameter for disabling early completions
I mention thi
Unfortunately this adds an "if" to the critical path.
You should at least use OPAL_UNLIKELY..
On Mar 3, 2008, at 12:28 PM, Jeff Squyres wrote:
The topic of the "early completion" behavior in OB1 for IB
optimizations has come up several times in the v1.2 series (it causes
problems in some scena
I personally have no objection, but I would ask then that the wiki be
modified to cover this case. All I require is that someone define the syntax
to be used to indicate "this is a node I do -not- want used", or
alternatively a flag that indicates "all nodes below are -not- to be used".
Implementa
On Mar 3, 2008, at 12:48 PM, Shipman, Galen M. wrote:
Unfortunately this adds an "if" to the critical path.
You should at least use OPAL_UNLIKELY..
I could have sworn there was no OPAL_UNLIKELY in the 1.2 series, which
is why I didn't add it. But I just checked right now and I see that
it
./orte/mca/errmgr/errmgr.h(135): warning #1286: invalid attribute for
"orte_errmgr_base_module_abort_fn_t"
typedef void (*orte_errmgr_base_module_abort_fn_t)(int error_code, char
*fmt, ...) __opal_attribute_format__(__printf__, 2, 3);
I think the issue is that you can't apply attributes to the ty
We have several options in configure that take lists as their argument. Yet
there appears to be no way for a user to find out valid members for those
lists.
For example, we have the option --enable-contrib-no-build. Is there some way
that the user and/or sys admin can find out what contributed pac
Has anyone else noticed that the time required to build the trunk after a
configure has gone up considerably over the last few months? It used to take
about 5 min on my G5 Mac desktop - it now takes a solid 15+ min (both times
not including autogen or configure).
Interestingly, I tried it configur
On Mar 3, 2008, at 1:16 PM, Ralph H Castain wrote:
We have several options in configure that take lists as their
argument. Yet
there appears to be no way for a user to find out valid members for
those
lists.
For example, we have the option --enable-contrib-no-build. Is there
some way
that
FWIW, I just did some trivial tests:
make with vt: 7.19
make -j4 with vt: 2:49
make without vt: 6:29
make -j4 without vt: 2:32
On Mar 3, 2008, at 1:43 PM, Ralph H Castain wrote:
Has anyone else noticed that the time required to build the trunk
after a
configure has gone up considerably ove
13 matches
Mail list logo