Re: [Condor-users] Re: split processors among multiple jobs

[Matt Hope <matthew.hope@xxxxxxxxx>]

On Tue, 22 Mar 2005 15:30:31 -0600, Derek Wright <wright@xxxxxxxxxxx> wrote:
> On Tue, 22 Mar 2005 09:49:22 +0000  Matt Hope wrote:
> 
> > Does this apply if the jobs are, in essence, running only via the
> > ranking by the execute machines... So if the schedd puts another job
> > to the top of its list which is ranked lower by the execute machines
> > this will not cause the currently running job previously at the top
> > (which presumably had at least as good a machine rank) to be
> > preempted.
> 
> machine RANK expressions will *always* result in preemption.  if any
> job in the system is ranked higher by a given machine, the startd will
> preempt whatever it's doing for the "better" job.  the only thing that
> can prevent this kind of preemption from killing a job is the
> MaxJobRetirementTime stuff we added in 6.7.x.
> 
> job priorities on their own will *never* result in preemption.

Sorry I explained that badly:
Say I have job A in the queue with prio 0 which is ranked by a
particular startd S as 50 (this rank is determined by another job
attribute entirely unrelated to job prio). It is currently running on
S.
There exists another job X on another schedd from a different user
which gets ranked as 40 by S. it isn't running.
I now submit a job B with prio 10 which the S ranks as 30.
In addition I have a whole bunch of (lets say 3) jobs running on other
machines Y1, Y2 and Y3 due to a high rank thus I have, according to
the fixed condor user prio settings, more than my 'fair' share of the
pool. They have a prio of 1 but rank at 10 on S (their ranking on the
other machines is much higher)

On the next negotiation cycle the first jobs dealt with by the
negotiator will be X, followed by B, Y1, Y2, Y3, A. (since I have a
jobs running the other user gets first chance).
X is evaluated against the startd rank 40. B is also compared the rank
is lower so the X match is kept. At this stage we move onto the next
pie spin, since I already have a large proportion of the machines In
the farm I am considered to have exceeded my schedd limit and since we
are no longer on the first spin I don't even get a chance to evaluate
the startd ranking for job A.
At the end of the full cycle the machine is now definitely matched
against X not A and A get's kicked despite its better ranking by the
machine simply because the negotiator never got round to evaluating
both.

I hope that example explains what I'm getting at, though it's still a
little fuzzy.
I could be misunderstanding the negotiation behaviour however.
 
> if you're using machine rank for anything, then yes, you have to watch
> out for possible preemption.  hope this helps.  sorry preemption is
> such a confusing topic...

Indeed - I was going to suggest the addition of a MACHINE_RANK_PREEMPT
expression but having looked at it further that would be rather
complex.

Matt