New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a SCRAM toolfile for Intel VTune #2681
Add a SCRAM toolfile for Intel VTune #2681
Conversation
A new Pull Request was created by @fwyzard (Andrea Bocci) for branch IB/CMSSW_9_0_X/gcc530. @cmsbuild, @smuzaffar, @iahmad-khan, @davidlange6 can you please review it and eventually sign? Thanks. |
a85bdc2
to
5360e5c
Compare
please test |
The tests are being triggered in jenkins. |
This should be included in CMSSW only on top of cms-sw/cmssw-config#56 . |
<client> | ||
<environment name="INTEL_VTUNE_BASE" default="/afs/cern.ch/sw/IntelSoftware/linux/x86_64/xe2017/vtune_amplifier_xe_%{realversion}"/> | ||
<environment name="INCLUDE" default="$INTEL_VTUNE_BASE/include"/> | ||
<environment name="LIBDIR" default="$INTEL_VTUNE_BASE/lib64"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this directory contains libstdc++. this can cause problems. Looks like vtune executables linked with full path e.g.
libstdc++.so.6 => /afs/cern.ch/sw/IntelSoftware/linux/x86_64/xe2017/vtune_amplifier_xe_2017.0.2.478468/bin64/./../lib64/libstdc++.so.6 (0x00007f4003603000)
So I guess we can drop it and instead add
<flags LDFLAGS="$(INTEL_VTUNE_BASE)/lib64"/>
@smuzaffar I see your point, however that does not seem to happen: after setting up the intel-vtune tool in CMSSW, I do not see its library path added to LD_LIBRARY_PATH:
|
Comparison job queued. |
@fwyzard , ah right. SCRAM only adds the path in LD_LIBRARY_PATH if tool has explicitly ask it to do so
so this toolfile should be fine. |
</tool> | ||
EOF_TOOLFILE | ||
|
||
## IMPORT scram-tools-post |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure, if this is going to create the correct init.sh and init.csh files. As you do not have an explicit -toofile, so I would suggest to not import scram-tools-post but just add explicit %post section like https://github.com/cms-sw/cmsdist/blob/IB/CMSSW_9_0_X/gcc530/scram-tools-post.file#L19 (use INTEL_VTUNE instead of %{BaseTool}_TOOLFILE).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean like
%post
if [ "$CMS_INSTALL_PREFIX" = "" ] ; then CMS_INSTALL_PREFIX=$RPM_INSTALL_PREFIX; export CMS_INSTALL_PREFIX; fi
%{relocateConfig}etc/scram.d/*.xml
echo "INTEL_VTUNE_ROOT='$CMS_INSTALL_PREFIX/%{pkgrel}'" > $RPM_INSTALL_PREFIX/%{pkgrel}/etc/profile.d/init.sh
echo "set INTEL_VTUNE_ROOT='$CMS_INSTALL_PREFIX/%{pkgrel}'" > $RPM_INSTALL_PREFIX/%{pkgrel}/etc/profile.d/init.csh
?
But there is nothing to relocate, and there is nothing that makes use of $INTEL_VTUNE_ROOT .
Maybe I should just have an empty %post
section ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scramv1-tool-conf.file (which collects all toolfiles and bundle them in tool-conf) needs to access the <tool>_ROOT
env. So each tool should set it.
If you provide an empty %post section then cmsBuild is anyway going to generate init.sh with default values for ROOT, VERSION, PATH, LD_LIBRARY_PATH etc (just a standard init.sh file). As for toofiles we do not need any of these that is why we re-create init.* with only _ROOT variable in them.
</client> | ||
<runtime name="PATH" value="$INTEL_VTUNE_BASE/bin64" type="path"/> | ||
<runtime name="VTUNE_AMPLIFIER_XE_2017_DIR" value="$INTEL_VTUNE_BASE"/> | ||
<runtime name="INTEL_LICENSE_FILE" value="28518@lxlicen01.cern.ch,28518@lxlicen02.cern.ch,28518@lxlicen03.cern.ch" type="path" handler="warn"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
drop this one too, I will set it via intel-license toolfile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - but there is not such toolfile for the time being. Do you want me to add one ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a one here
7cfbfa5
it should be available in next IB
Understood, thanks. I'll fix it. |
5360e5c
to
f16f42a
Compare
Pull request #2681 was updated. |
please test |
The tests are being triggered in jenkins. |
The error does not seem to come from this PR ?
|
@fwyzard , forgot to mention that you need to add |
f16f42a
to
934d0a4
Compare
please test |
The tests are being triggered in jenkins. |
Pull request #2681 was updated. |
please test |
The tests are being triggered in jenkins. |
Pull request #2681 was updated. |
Both should be done. Should there be an explicit dependency on intel-license ? How does one make sure it ends up in the "selected" tools instead of the "available" ones ? |
All tools build via cmssw-tool-conf are by default selected unless explicitly ignored. intel-license is not ignored , so it should be selected and should already be visible in 90X IBs. |
Comparison job queued. |
Comparison is ready The workflows 1003.0, 1001.0, 1000.0, 140.53, 136.731, 4.22 have different files in step1_dasquery.log than the ones found in the baseline. You may want to check and retrigger the tests if necessary. You can check it in the "files" directory in the results of the comparisons |
No description provided.