You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An idea (already mentioned to @milroy and @trws) is to have a single traversal that can handle cleanup of reservations. I can talk about this in context of the easy queue policy.
What we do now is have an m_reserved queue, where we store the flux ids of jobs that are reserved. Easy has a reservation depth of 1, so technically that's only one job (and this optimization not useful there) but if we extend this to other queue policies that have +1 reservation, this approach might be useful. Instead of issuing different cancels for N reservations (flux ids) we might instead have a single call (function, mapping to a traverser, and exposed also as part of our various APIs) that can simply clear all reservations. If the developer user wants to clear a subset, they would use the cancel approach.
This might be an improvement to simplify design - for the policies that want to cancel all of them and are currently storing the ids, we would just make one call to the API. It would also (maybe?) be more efficient (faster?) as a single traversal.
Put up an issue for this if you would, and make a note that we could make it a single traversal that way as well. I haven't looked closely at the code for the other policies, but I suspect I'll want to implement similar in Fluxnetes and will soon.
The text was updated successfully, but these errors were encountered:
An idea (already mentioned to @milroy and @trws) is to have a single traversal that can handle cleanup of reservations. I can talk about this in context of the easy queue policy.
What we do now is have an
m_reserved
queue, where we store the flux ids of jobs that are reserved. Easy has a reservation depth of 1, so technically that's only one job (and this optimization not useful there) but if we extend this to other queue policies that have +1 reservation, this approach might be useful. Instead of issuing different cancels for N reservations (flux ids) we might instead have a single call (function, mapping to a traverser, and exposed also as part of our various APIs) that can simply clear all reservations. If the developer user wants to clear a subset, they would use the cancel approach.This might be an improvement to simplify design - for the policies that want to cancel all of them and are currently storing the ids, we would just make one call to the API. It would also (maybe?) be more efficient (faster?) as a single traversal.
Put up an issue for this if you would, and make a note that we could make it a single traversal that way as well. I haven't looked closely at the code for the other policies, but I suspect I'll want to implement similar in Fluxnetes and will soon.
The text was updated successfully, but these errors were encountered: