On Oct 29 15:03 +0000, William Hay wrote:
> > Does that indicate that the scheduler already reserved 4x8 slots on 4
> > nodes? If so, then this information is not correct since we have only 16
> > slots free in that queue right now.
>
> It's reserving all the slots it might need not just the ones that are
> currently free but the ones it anticipates being free. If it didn't
> do this it might in some circumstances
> overcommit occupied slots.
OK yes, I saw that it always reserves the requested number of slots, free
or not. Makes sense. Does the system switch reservation from used to free
slots if more slots become free (I guess that's default)?
> > Where does SGE store reservation-related information -- only in memory
> > or also in a file (which I could not locate anywhere)?
> >
> There isn't really a reservation state to save. The reservations are
> remade anew every scheduling cycle but tend to be stable because the
> same algorithm is used against a cluster state where the only new
> resource usage since the last scheduling cycle is compatible with the
> reservations made last cycle. That said there can be some funny
> heuristic based reservation wobble at times.
OK, so basically the "reservation state" is the job database.
We had small jobs backfilling a big one with reservation (free + used
slots). Looking closer, we see that this backfilling happens indeed only
when the small jobs have a smaller runtime than that of the jobs using
reserved slots.
Another question, related to reservation:
We have two PEs, which differ only in allocation_rule. The PE with
allocation_rule $fill_up
does reservation, while
allocation_rule 8
(to request complete 8-core nodes) doesn't. Why may that be?
Thanks very much.
best,
Steve
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
