[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] How to modify cpus

Sent from my iPhone

> On May 15, 2016, at 11:56 AM, Brian Candler <b.candler@xxxxxxxxx> wrote:
>> On 13/05/2016 14:48, Rich Pieri wrote:
>>> On 5/13/16 9:08 AM, sjones wrote:
>>> # cat /etc/condor/config.d/00-node_parameters
>>> NUM_SLOTS = 1
>>> SLOT_TYPE_1               = cpus=32,mem=auto,disk=auto
>>> NUM_SLOTS_TYPE_1          = 1
>>> Yet the system continues to run the previous number, cpus=24.
>> Try "NUM_CPUS = 32" to override the detected CPU count.
>> As a rule of thumb, though, you should not allocate more CPUs or cores
>> than you actually have. Running two jobs on one core simultaneously will
>> take longer for both to complete than running each job sequentially on
>> the same core.

Unless you enable hyperthreading - in that case, depending on the application, I've seen a 40% increase in throughput or an overall slowdown.

In CMS, we've been looking at over committing slightly for very specific workflows (jobs that are guaranteed to be network or IO bound).

> That's unless your jobs are doing significant amounts of other activity (in particular disk or network I/O), in which case you may need to pretend that there are more cores than you really have in order to utilise them fully.

Yup, all sorts of things can depend on the workload - and can go awry when the workload changes (spoken as a person who overcommits memory).  

So, it's a risk - but a risk with potential payoffs.

> Last time I looked at this, I wasn't able to make a job request a fraction of a CPU, although it was a while ago since I last tried that.

This is still correct.  You currently cannot be allocated 0 CPUs either.

> Also: if a slot advertises one CPU, when a matched job runs I don't think it will be prevented from using more than one CPU, unless you are using cgroups enforcement.

CPU pinning is also available.

> Regards,
> Brian.
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/