https://bugzilla.redhat.com/show_bug.cgi?id=830869
--- Comment #30 from Jaroslav Å karvada <jskarvad(a)redhat.com> ---
(In reply to Zbigniew Jędrzejewski-Szmek from comment #29)
> > The binary currently tries to open /etc/hpl/HPL.dat and
segfaults. I think
> > it should be patched to use the new location.
> >
> Please see previous discussion on HPL.dat location. I finally moved HPL.dat
> to /usr/share/hpl, but I am not sure whether it is good thing to add a
> fallback for HPL to read the file from there, probably it isn't.
> Nevertheless it shouldn't coredump. I patched it to cleanly exit.
I don't see why it shouldn't. What about the following simpler patch:
--- a/testing/ptest/HPL_pdinfo.c
+++ b/testing/ptest/HPL_pdinfo.c
@@ -294,11 +294,12 @@
/*
* Open file and skip data file header
*/
- if( ( infp = fopen( "HPL.dat", "r" ) ) == NULL )
+ if( ( infp = fopen( "HPL.dat", "r" ) ) == NULL &&
+ ( infp = fopen( "/usr/share/hpl/HPL.dat", "r" ) ) ==
NULL)
{
HPL_pwarn( stderr, __LINE__, "HPL_pdinfo",
"cannot open file HPL.dat" );
- error = 1; goto label_error;
+ exit( 1 );
}
(void) fgets( line, HPL_LINE_MAX - 2, infp );
This way the package does something useful out-of-the-box, and gives a rough
test/benchmark of the mpi installation. If the user wants to customize, they
can provide their own HPL.dat file in $CWD.
My previous opinion was the same - that it could do something useful out of the
box. So shouldn't be better to use /etc/hpl/HPL.dat?
> > README.Fedora still refers to mpich2. It's mpich now.
> >
> Fixed and also updated regarding HPL.dat location.
hpl-README.Fedora still has old contents ("mpich2").
Sorry, I mistakenly built the package from the old cached sources.
> > Shouldn't this be run in %check? It would test both mpi
implementations on
> > all archs.
> >
> I am currently not sure. Did you mean running the HPL benchmark by hand over
> all available implementations? And with which configuration? With the
> supplied example HPL.dat? What number of processes to use? One? Is it good
> thing to do?
Yes, that's what I'd do. Something like this:
%check
%{_openmpi_load}
mpirun -n 4 xhpl_openmpi
%{_openmpi_unload}
%{_mpich_load}
mpirun -n 4 xhpl_mpich
%{_mpich_unload}
This takes about two seconds on my machine. I guess it'd vary a lot between
architectures, but should not be more then maybe ten seconds anywhere. The
point is less to benchmark anything, but rather to test that it still runs
at all. I think 4 is a good number, even if compiling on one cpu: high
enough to test that things work, but does not consume undue resources.
Makes sense, I think that load of koji builders will be negligible.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component