On 29 October 2012 18:08, Steve Schmerler <[email protected]> wrote:
> 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)? Since it has no memory it will "switch" to whichever slots it considers best each cycle. It doesn't always make what I would consider the best possible reservation though. > >> > 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? > No idea. All our PEs are $full_up. There are some bugs in the reservation logic though possibly you've been bitten by one. William William _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
