| Hi Jeff,
The ConsumptionPolicies really just do what they say, nothing more. They allow multiple jobs to match the same partition able slot *during one cycle*. They donât allow matching them at once, or even selecting the best job to match. Basically, ConsumptionPolicies allow the Negotiator to *immediately compute* the remainder after a match. Otherwise, it has to *wait* for the job to actually land on the slot, have its resources carved out, then the remainder reported back to the collector, which then is *observed* by the Negotiator in a future cycle.
The Negotiator will still just match one slot after another. Itâs just that âone after anotherâ gets compressed into one negotiation cycle. What this buys you is the option for depth-first filling (the negotiator can proceed filling the same slot instead of having to look at another) and faster turnaround (because more matches can be made per cycle).
The options donât define âbestâ, they really just define whether this mechanism is used at all (CONSUMPTION_POLICY) and how large/small the carved out slots are compared to the request.
Cheers, Max
On 4. Feb 2026, at 09:18, Jeff Templon <templon@xxxxxxxxx> wrote:
Hi,
Weâre looking into how to effectively deal with scheduling of GPU jobs here. In the manual, GPUs are mentioned in âconsumption policiesâ. How to set one up is pretty well documented, what is not documented (at least, not in the section explaining how to configure them) is what a consumption policy actually DOES. There are these two bits:
For partitionable slots, the specification of a consumption policy permits matchmaking at the negotiator. A dynamic slot carved from the partitionable slot acquires the required quantities of resources, leaving the partitionable slot with the remainder. This differs from scheduler matchmaking in that multiple jobs can match with the partitionable slot during a single negotiation cycle.
and
and that the resource this policy cares about allocating are the cores.
Summary, matchmaking can happen at the negotiator, multiple jobs can match the slot during a single negotiation cycle, and you can tell it which resource to care about. I still donât see what that âcaring aboutâ means in practice - presumably matching multiple jobs in a single cycle means that you can pick the best match? And what defines âbestâ if I have only CONSUMPTION_POLICY = True defined? And is that different than if I have SLOT_TYPE_1_CONSUMPTION_CPUS = TARGET.RequestCpus defined? Thanks in advance, JT
_______________________________________________ HTCondor-users mailing list To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a subject: Unsubscribe The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}