Doug,<div><br></div><div>I have created a ticket for our documentation team to note that the TDK is where nvml.h can be found.</div><div><br></div><div>We also thank you for the patch. I believe there is some more work that needs to be done beyond just this change, but we will look to get those done very soon. I think it would be ideal to allow people to use the same binary for both GPU enabled and non-GPU enabled nodes.</div>
<div><br></div><div>David<br><br><div class="gmail_quote">On Thu, Feb 16, 2012 at 1:49 PM, Doug Johnson <span dir="ltr">&lt;<a href="mailto:djohnson@osc.edu">djohnson@osc.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Axel, thanks for the clarification.  David, can you update the<br>
documentation to clarify that the Tesla Deployment Kit is needed to<br>
for nvml.h?  The TDK is not linked to from the normal CUDA download<br>
pages, and are a bit obscure.<br>
<br>
However, when this option is enabled (at least in torque-2.5.10),<br>
pbs_mom will immediately exit if the node does not have a gpu.<br>
Clusters that have a mix of GPU and non-GPU nodes are common.  Could<br>
we do something like the following instead?<br>
<br>
--- mom_server.c~       2012-01-12 16:34:39.000000000 -0500<br>
+++ mom_server.c        2012-02-16 14:51:17.480860518 -0500<br>
@@ -1255,7 +1255,7 @@<br>
<br>
   rc = nvmlInit();<br>
<br>
-  if (rc == NVML_SUCCESS)<br>
+  if (rc == NVML_SUCCESS || rc == NVML_ERROR_DRIVER_NOT_LOADED)<br>
     return (TRUE);<br>
<br>
   log_nvml_error (rc, NULL, id);<br>
<br>
This would allow systems without GPUs to start the same mom as the GPU<br>
nodes.  Ideally the API would also have an error such as<br>
NVML_ERROR_NO_DEVICE that would be returned if no nvidia devices<br>
existed in the system (check for pci devices, don&#39;t rely on driver<br>
initialization failure as that&#39;s ambiguous.)<br>
<br>
Doug<br>
<br>
<br>
At Wed, 15 Feb 2012 18:56:36 -0500,<br>
<div class="HOEnZb"><div class="h5">Axel Kohlmeyer wrote:<br>
&gt;<br>
&gt; On Wed, Feb 15, 2012 at 6:54 PM, Doug Johnson &lt;<a href="mailto:djohnson@osc.edu">djohnson@osc.edu</a>&gt; wrote:<br>
&gt; &gt; Hi David,<br>
&gt; &gt;<br>
&gt; &gt; I was going to send a separate email about &#39;--with-nvml-include&#39; once<br>
&gt; &gt; I had more time to look at the problem.  It seems that nvml.h no<br>
&gt; &gt; longer exists in the newer versions of the CUDA SDK.  We have version<br>
&gt;<br>
&gt; <a href="http://developer.nvidia.com/nvidia-management-library-NVML" target="_blank">http://developer.nvidia.com/nvidia-management-library-NVML</a><br>
&gt;<br>
&gt; axel.<br>
&gt;<br>
&gt; &gt; 4.1.28 of both the gpucomputingsdk and cudatoolkit, there is no nvml.h<br>
&gt; &gt; and enabling this option in torque results in failure to build.  I<br>
&gt; &gt; Haven&#39;t had a chance to take a look at older versions or the release<br>
&gt; &gt; notes for descriptions of when this changed.<br>
&gt; &gt;<br>
&gt; &gt; Is it safe to assume that if we were able to use this code, a context<br>
&gt; &gt; to the cards would be kept open by the mom?<br>
&gt; &gt;<br>
&gt; &gt; Doug<br>
&gt; &gt;<br>
&gt; &gt; At Wed, 15 Feb 2012 16:22:09 -0700,<br>
&gt; &gt; David Beer wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; [1  &lt;multipart/alternative (7bit)&gt;]<br>
&gt; &gt;&gt; [1.1  &lt;text/plain; ISO-8859-1 (7bit)&gt;]<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; [1.2  &lt;text/html; ISO-8859-1 (quoted-printable)&gt;]<br>
&gt; &gt;&gt; Doug,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Have you tried using the --with-nvml-include=&lt;path&gt; option in configure? This has pbs_mom use the<br>
&gt; &gt;&gt; nvidia API for these calls, and should speed things up a bit. The path should be the path to the nvml.h<br>
&gt; &gt;&gt; file and is usually:<br>
&gt; &gt;&gt; /usr/local/cuda/CUDAToolsSDK/NVML/<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; David<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On Wed, Feb 15, 2012 at 4:15 PM, Doug Johnson &lt;<a href="mailto:djohnson@osc.edu">djohnson@osc.edu</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     Hi,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     Has anyone noticed the overhead when enabling GPU support in torque?<br>
&gt; &gt;&gt;     The nvidia-smi process requires about 4 cpu seconds for each<br>
&gt; &gt;&gt;     invocation.  When executing a non-GPU code that uses all the cores<br>
&gt; &gt;&gt;     this results in a bit of oversubscription of the cores.  Since<br>
&gt; &gt;&gt;     nvidia-smi is executed every 30 seconds to collect card state this<br>
&gt; &gt;&gt;     results in a measurable decrease in performance.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     As a workaround I&#39;ve enabled &#39;persistence mode&#39; for the card.  When<br>
&gt; &gt;&gt;     not in use, the card is apparently not initialized.  With persistence<br>
&gt; &gt;&gt;     mode enabled the cpu time to execute the command is reduced to ~0.02.<br>
&gt; &gt;&gt;     This will also help with the execution time of short kernels, as the<br>
&gt; &gt;&gt;     card will be ready to go.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     Do other people run with persistence mode enabled?  Are there any<br>
&gt; &gt;&gt;     downsides?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     Doug<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;     PS. I think if X were running this would not be an issue.<br>
&gt; &gt;&gt;     _______________________________________________<br>
&gt; &gt;&gt;     torqueusers mailing list<br>
&gt; &gt;&gt;     <a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
&gt; &gt;&gt;     <a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; --<br>
&gt; &gt;&gt; David Beer | Software Engineer<br>
&gt; &gt;&gt; Adaptive Computing<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; [2  &lt;text/plain; us-ascii (7bit)&gt;]<br>
&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; torqueusers mailing list<br>
&gt; &gt;&gt; <a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
&gt; &gt;&gt; <a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; torqueusers mailing list<br>
&gt; &gt; <a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
&gt; &gt; <a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Dr. Axel Kohlmeyer    <a href="mailto:akohlmey@gmail.com">akohlmey@gmail.com</a><br>
&gt; <a href="http://sites.google.com/site/akohlmey/" target="_blank">http://sites.google.com/site/akohlmey/</a><br>
&gt;<br>
&gt; Institute for Computational Molecular Science<br>
&gt; Temple University, Philadelphia PA, USA.<br>
&gt; _______________________________________________<br>
&gt; torqueusers mailing list<br>
&gt; <a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
&gt; <a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
_______________________________________________<br>
torqueusers mailing list<br>
<a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
<a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>David Beer | Software Engineer</div><div>Adaptive Computing</div><br>
</div>