Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Question about scheduler support
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-05-15 14:07:50


Hi Gus

The issue is that you have to work thru all the various components (leafing thru the code base) to construct a list of all the things you *don't* want to build. By default, we build *everything*, so there is no current method to simply "build only what I want".

For those building static, for example, this results in a much larger binary than really necessary. Those wanting a minimal build to avoid confusion (e.g., "why do i show slurm when I'm running moab?") face a similar issue.

What we agree on is the need to provide the "build only what I want" capability. What Maxime has proposed is one way of doing that for at least the schedulers. Jeff and I are discussing additional options.

On May 15, 2014, at 10:59 AM, Gus Correa <gus_at_[hidden]> wrote:

> Hi List
>
> Sorry, but I confess I am having a hard time to understand
> all the fuss about this.
>
> At least in OMPI 1.6.5 there are already
> two configure options that just knock out support for slurm and
> loadleveler if they are set to "no", hopefully for the joy of everybody
> that want lean and mean OMPI installations.
> (Maybe those options are available in OMPI 1.8.1 also?
> I haven't tried it.)
>
> Just configure:
>
> --with-slurm=no --with-loadleveler=no
>
> One could go on and on and make a comprehensive list of all options
> that one wants in/out, and configure with/without all of them.
>
> **
>
> Isn't this level of simplicity, effectiveness, and of
> standard use of configure options, good enough for us?
>
> Works for me.
>
> **
>
> IMHO, what would help is to very clearly document
> on the "configure --help" output what is the default value of
> *all* options.
>
> This would allow system administrators and other users to safely
> make informed choices (or just let the defaults go, if they prefer).
> Although I must say right now "configure --help" is not that bad at all. I am not frustrated with it. It may need only a few tweaks.
>
> Currently the --with-slurm and --with-loadleveler options
> are clearly documented as having "yes" as the default.
> However, other options don't have so clearly documented defaults.
> In particular -with-tm Torque (which seems to depend on its libraries and headers being found or not by configure).
> By contrast --with-sge clearly says "no" is the default.
>
> This covers pretty much all free/open source schedulers,
> correct me if I am wrong, please.
>
> LSF seems not to have a clearly documented default also.
> But LSF is for the rich. I am out.
>
> My 2 cents, 2nd edition, out of print.
> Bye, thanks, regards.
> Gus Correa
>
>
> On 05/15/2014 09:35 AM, Jeff Squyres (jsquyres) wrote:
>> These are all good points -- thanks for the feedback.
>>
>> Just to be clear: my point about the menu system was to generate file that could be used for subsequent installs, very specifically targeted at those who want/need scriptable installations.
>>
>> One possible scenario could be: you download OMPI, run the menu installer so that you can see the options that are available, pick the ones you want, generate the file, and then use it in automated installs (e.g., ./configure --only-build-this-stuff=file_I_created_from_menu_installer).
>>
>> I am presuming that the generated file will be text, so it could be built/edited by hand, too. This is heavily inspired by the Linux kernel's "make menuconfig": it generates a .config file that you can use for subsequent builds.
>>
>> We can also look at the possibility of providing a template file that lists all options that are available in that particular tarball (similar to the Linux kernel "make config").
>>
>> This, BTW, is one part where we need to build some new infrastructure: to register and discover all available options (history has shown that just maintaining a text file for a project the size of Open MPI is not feasible -- it'll get stale/out of date).
>>
>> Other large projects do this kind of thing; we need to see if there's any ideas/code we can borrow rather than completely re-inventing the wheel.
>>
>> Again, these are just my thoughts after having thought about this for only about 30 minutes -- so this is likely quite rough and may not even resemble what we finally end up with.
>>
>>
>> On May 15, 2014, at 8:51 AM, Noam Bernstein <noam.bernstein_at_[hidden]> wrote:
>>
>>> I’m not sure how this would apply to other options, but for the scheduler, what about no scheduler-related options defaults to everything enabled (like before), but having any explicit scheduler enable option disables by default all the other schedulers? Multiple explicit enable options would enable all the requested schedulers, and disable everything else.
>>>
>>> Noam
>>> _______________________________________________
>>> users mailing list
>>> users_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>
>>
>
> _______________________________________________
> users mailing list
> users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/users