On Thu, 24 Jul 2014 10:24:11 +0000 Daniel Gruber <dgru...@univa.com> wrote:
> Hi Atul, > > We have included Intel Xeon Phi Support for Univa Grid Engine > in the year 2012 in Univa Grid Engine 8.1.3. For that it required > to add some new functionality which was missing in Sun Grid Engine. > > So basically what we did was: > > - Create a new resource type which allows you to do a mapping > between a job and the selected MIC. This is needed in order > to manage the mapping easily. Is this the RSMAP resource type or did you add something else? > - Adding support so that a MIC binary can be submitted directly > to the cluster (which is then executed on a free MIC). Presumably this could be implemented by using a queue with a custom starter_method on other versions of Grid Engine. > - Added an customizable load sensor which allows you to > monitor and account the state of the MICs (power consumption, > different temperatures, etc.) Instantaneous power consumption or kilowatt hours? > - Added a command line tool with similar functionality Don't these already exist in Intel's MPSS toolkit? > - Added support for hybrid application which run partially on > the normal Intel processor and offloads some function calls > to the Intel Xeon Phi. This support includes that a job is > automatically bound to the socket on which the selected Intel Xeon Phi > card is attached to with the PCIexpress interface. > > Running an execd directly on the Intel Xeon Phi is not what we > wanted todo since in some cases people want to restart the > the co-processors after a job run / like on GPUs in order to > reap the memory for privacy (just one reason). When it comes to > KNL then things might change. Could this not be accomplished with an execd by having the epilog trigger a shutdown of the MIC combined with some code on the host to conditionally restart it if it is down? Presumably in this(and most other) circumstance the user would have requested exclusive access to the MIC. > > With kind regards and sorry for posting this on our open source > mailing list. But I think it could be from general interest. I don't think we're an open source list as such but we are generally more able to help others with the open source versions of Grid Engine. People who use Oracle Grid Engine or Univa Grid Engine presumably have a support contract with Univa that allows them to access support resources anyway. As such I don't think there is any need to apologise for a posting that is directly responsive to someone's query even if the implied suggestion is basically why not upgrade to Univa Grid Engine. William
signature.asc
Description: PGP signature
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
