Re: [slurm-users] Testing Lua job submit plugins

Hi Michael, Michael Robbert writes: > I’m wondering if others in the Slurm community have any tips or best > practices for the development and testing of Lua job submit plugins. Is there > anything that can be done prior to deployment on a production cluster that > will help to ensure > the c

Re: [slurm-users] [External] Re: Testing Lua job submit plugins

I've used that approach too. If the submitting user ID is mine, then do this or that, all other's take the else clause. That way, you can actually run on the production system without having to replicate the whole environment in a sandbox. Certainly not the cleanest approach, but it doesn't hurt

Re: [slurm-users] Testing Lua job submit plugins

We have developed a set of unit tests based on LuaUnit for our clusters' submit filters. --Troy From: slurm-users On Behalf Of Michael Robbert Sent: Thursday, May 6, 2021 1:11 PM To: Slurm User Community List Subject: [slurm-users] Testing Lua job submit plugins I'm wondering

Re: [slurm-users] Testing Lua job submit plugins

We go the route of having a test cluster and vetting our lua scripts there before putting them in the production environment. -Paul Edmon- On 5/6/2021 1:23 PM, Renfro, Michael wrote: I’ve used the structure at https://gist.github.com/mikerenfro/92d70562f9bb3f721ad1b221a1356de5

Re: [slurm-users] Testing Lua job submit plugins

I’ve used the structure at https://gist.github.com/mikerenfro/92d70562f9bb3f721ad1b221a1356de5 to handle basic test/production branching. I can isolate the new behavior down to just a specific set of UIDs that way. Factoring out code into separate functions helps, too. I’ve seen others go so f

[slurm-users] Testing Lua job submit plugins

I’m wondering if others in the Slurm community have any tips or best practices for the development and testing of Lua job submit plugins. Is there anything that can be done prior to deployment on a production cluster that will help to ensure the code is going to do what you think it does or at t

[slurm-users] Selecting OpenCL GPU reliably

It is now possible for programs to do a precise and reliable selection of the GPU by first issuing a query to OpenCL with the clGetDeviceInfo() function with the param_name parameter set to cl_khr_pci_bus_info. This extension is available starting from OpenCL 3.0.7 References: - https://github.c

Re: [slurm-users] CUDA vs OpenCL

On Thu, 2021-05-06 at 08:58 +, Williams, Gareth (IM&T, Black Mountain) wrote: > ROCR_VISIBLE_DEVICES Is the closer analogy. GPU_DEVICE_ORDINAL is in > principle more generic (though does have GPU in the name). OpenCL > could in principle (can!) run on other devices which could/can have > more e

Re: [slurm-users] CUDA vs OpenCL

ROCR_VISIBLE_DEVICES Is the closer analogy. GPU_DEVICE_ORDINAL is in principle more generic (though does have GPU in the name). OpenCL could in principle (can!) run on other devices which could/can have more exotic topology, but for the sake of simplicity are likely to be presented as a list of

Re: [slurm-users] CUDA vs OpenCL

On Thu, 2021-05-06 at 08:00 +, Williams, Gareth (IM&T, Black Mountain) wrote: > The post has me thinking so I did a little searching... AMD have an > offering that supports OpenCL and they are not NVIDIA. They use a > different approach: > https://rocmdocs.amd.com/en/latest/Programming_Guides/O

Re: [slurm-users] CUDA vs OpenCL

The post has me thinking so I did a little searching... AMD have an offering that supports OpenCL and they are not NVIDIA. They use a different approach: https://rocmdocs.amd.com/en/latest/Programming_Guides/Opencl-programming-guide.html#masking-visible-devices FWIW I did not yet see anything ther

Re: [slurm-users] CUDA vs OpenCL

On Wed, 2021-04-28 at 10:56 +0200, Valerio Bellizzomi wrote: > Greetings, > I see here https://slurm.schedmd.com/gres.html#GPU_Management that > CUDA_VISIBLE_DEVICES is available for NVIDIA GPUs, what about OpenCL > GPUs? > > Is there an OPENCL_VISIBLE_DEVICES ? > > Lack of followup lets me co