Red Hat Bugzilla – Bug 429198
[RFE] Include SLURM in HPC Layered offering
Last modified: 2011-10-19 14:36:01 EDT
Escalated to Bugzilla from IssueTracker
Include SLURM in HPC Layered offering This event sent from IssueTracker by kbaxley [LLNL (HPC)] issue 36716
LLNL has been developing an GPL batch job scheduler. It makes it the software that essentially glues the cluster together. It allows the cluster administrator to carve up the cluster into seperate sections, order and prioritize jobs based upon cluster availability and use policy. It also allows users to specify job requirements, so that the adminisrator knows where and how to schedule it on the cluster. The batch scheduler also does the job of actually running the executable on the various cluster machines, cleaning up after the job has used up its allocation and accounting for supercomputer usage. There are a handful of batch schedulers out there which could be incorporated into a RHEL4 based HPC offering. SLURM is the one that LLNL is developing. It is GPL which is a distinct advantage over schedulers. It is also being actively maintained another advantage. This event sent from IssueTracker by kbaxley [LLNL (HPC)] issue 36716
Date: Wed, 18 Jan 2006 11:37:49 -0800 From: Morris Jette <jette@llnl.gov> Subject: SLURM version 1.0 now available X-Sender: jette@mail-lc.llnl.gov To: linux-admin@mail-lc.llnl.gov Message-id: <p06020417bff44934c4d2@[134.9.94.94]> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT SLURM v1.0 is available in the usual place. We plan for it to be deployed as part of Chaos 3.1. >We are please to announce the release of SLURM version 1.0. >It finally contains all of the capabilities we had planned >for at it's inception in 2002, plus a few more. The major >enhancements in version 1.0 include: > >* I/O streams for all tasks on a node are transmitted through a single > sockets instead of distinct sockets for each task. This improves > performance and scalability. >* Task affinity for binding tasks to CPUs. >* Nodes can be in multiple partitions, providing more flexibility in > managing the SLURM partitions as queues. >* Support for task communication/synchronization primitives (PMI). > This provides support for MPICH2. >* E-mail notification option on job state changes. >* Better control over task distribution (hostfile support). >* User control of job prioritization via nice option. >* Web-based configuration file building tool. >* Support to preempt/resume jobs. This means we can now support > gang scheduling. >* Support for deferred job initiation time specification. >* Compute node job shepherd now exec'ed program, slurmstepd. This > eliminates use of SysV shared memory and some problems in support > of the Native Posix Thread Library. >* Several bug fixes in interface with Maui Scheduler. >* For Blue Gene systems: support for small bglblocks. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Morris "Moe" Jette jette1@llnl.gov 925-423-4856 Integrated Computational Resource Management Group fax 925-423-6961 Livermore Computing Lawrence Livermore National Laboratory +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This event sent from IssueTracker by kbaxley [LLNL (HPC)] issue 36716
We should make this at least an option for MRG. Practically no one out there takes condor seriously for anything but cycle stealing of workstation. It doesn't scale to large and the latency of job starting is too high. Furthermore, it doesn't get out of the way of the job to be started as well as SLURM. This event sent from IssueTracker by kbaxley [LLNL (HPC)] issue 36716
Can we consider this as a possibility for EPEL? I would be willing to work with the slurm developers and redhat in packaging appropriately.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.