[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?
Satish
More information about the petsc-dev
mailing list