[petsc-dev] [Ideas-team] Seeking OLCF users complaining about poor build times

Satish Balay balay at mcs.anl.gov
Fri Feb 27 11:17:44 CST 2015

On Fri, 27 Feb 2015, Bartlett, Roscoe A. wrote:

> > > >Also I think such usage at LC centers might be prohibited.  And some
> > > >systems are configured in such a way that /tmp is really not useful
> > > >for source builds. [For eg - configure tends to do simpile runs - that
> > > >get blocked due to security settings on /tmp]
> > >
> > > Why would it be prohibited?  Especially if you remove the build after it's
> > > done?  What's a "simple run" and why do the security settings prohibit it?
> > 
> > I meant - "when configure creates and runs binaries - as part of configure
> > step in /tmp".
> > 
> > This is very rare -we might have seen 1 or 2 reports in past many
> > years [PETSc configure creates binaries in $TMPDIR and runs them] - so
> > not a real stumbling block.
> > 
> > However even if package builds are done in /tmp (a big improvement) -
> > most user code builds are not done in /tmp - so they will (repeatedly)
> > incur the nfs/pfs etc.. overhead.
> Is /tmp/ on these machines large enough to accommodate all of the users who want to build on a fast local disk?  Or is this only working because just a few people have figured this out and therefore can get away with this?
> The answer is always to configure and build on a fast local disk.  I have never seen a mounted file system that could complete with local native disk.

yes - /tmp is not scalable (when all users want to use it for builds)
- and users shouldn't have to looks for such workarrounds.

I guess the original premise of this discussion is what is the current
recomendation for users [of these machines] - and is the performance
acceptable? [It will be slower than local disk - but is it
annoyningly/prohibitively slow?]. Can this be improved?


More information about the petsc-dev mailing list