of note: current cpu_shares (which only exists on master) uses SlotWeight, where I think it should really be TotalSlotCpus.
Open Questions: Does anyone have a good way of *really* testing cpu_shares? What does over-subscription and fractions actually mean, or do we want to stick with whole numbers? ++How does this^ affect performance? Cheers, Tim ----- Original Message ----- > From: "Greg Thain" <[email protected]> > To: [email protected] > Sent: Monday, November 12, 2012 9:01:18 AM > Subject: Re: [HTCondor-devel] cpu affinity and partitionable slots > > On 11/09/2012 04:49 PM, Dan Bradley wrote: > > Hi all > > > > I was thinking about the lack of support in Condor for setting cpu > > affinity with partitionable slots in a useful way. We do this on > > our > > non-partitionable slots to avoid the inevitable accidents where > > jobs > > try to use the whole machine from a single-core slot. We'd like to > > be > > able to do it on the partitionable slots. > > > > My first question is whether cpu shares in cgroups make the above > > use-case of cpu affinity obsolete. > > Dan: > > We certainly want to have a solution for cpu-limiting in a > partitionable > slot world. One question is whether all of your clusters are ready > for > cgroups? I was surprised to learn this week that LIGO has worked > around > all of their Debian-related cgroup problems. > > All things being equal, I would prefer to do this with cgroups, as I > don't like having to lock a job to a particular physical CPU. > > -greg > > > _______________________________________________ > HTCondor-devel mailing list > [email protected] > https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel > _______________________________________________ HTCondor-devel mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel
