balloons: support configuring Linux scheduling parameters

[askervin]

No description provided.

[askervin]

@klihub, it might be wise to add either to applyProcessProperties() or to its caller a check if these properties are configurable. That would avoid a lot of unnecessary calls and their failures in cache's container object. If you agree, would you have a suggestion how to know if applying these properties makes sense?

[klihub]

@klihub, it might be wise to add either to applyProcessProperties() or to its caller a check if these properties are configurable. That would avoid a lot of unnecessary calls and their failures in cache's container object. If you agree, would you have a suggestion how to know if applying these properties makes sense?

Sorry, I'm not sure how to interpret the question. I mean, the policy call context (which NRI event we're processing, for what container, and which container's what property we consider updating) should determine whether a container's parameter can be updated. Is this what you are referring to ?

[klihub]

@klihub, it might be wise to add either to applyProcessProperties() or to its caller a check if these properties are configurable. That would avoid a lot of unnecessary calls and their failures in cache's container object. If you agree, would you have a suggestion how to know if applying these properties makes sense?

Sorry, I'm not sure how to interpret the question. I mean, the policy call context (which NRI event we're processing, for what container, and which container's what property we consider updating) should determine whether a container's parameter can be updated. Is this what you are referring to ?

One context where I see how policies can end up asking for impossible things is the initial Sync() for deleted and discovered containers. Both balloons and topology-aware basically implement it by looping through all deleted containers doing a ReleaseResources() then looping through all discovered/added containers doing a AllocateResources(). The latter, AllocateResources() is normally triggered by an NRI CreateContainer which is called prior to actually creating the container, but in this context it is called for an already created (and usually also already running) container.

Ideally on the AllocateResource() code paths the policy should check what is the current state of the container it is allocating resources for, and if it is Created or Running it should not bother with anything else than resource updates, which are still possible.

Additionally/ideally, we should consider updating the policy-level Sync() and allow it to return (evict []*Container, error) instead of just an error. Then the policy would have two alternatives during Sync() wrt. each discovered container: limit itself to updating/adjusting resources, or ask for the eviction of the container if the policy decision involves strictly required adjustments to the container which can't be done with an update. Then we could evict the requested containers (with fingers crossed assuming they'll get restarted) and then the policy could do the full set of necessary adjustments as they are recreated.

For the time being that eviction would require a bit of hack from the control flow point of view, since NRI Synchronize() can't return a list of containers to evict, so we'd need to make an unsolicited NRI UpdateContainers() request to ask for eviction. But I think we should update the core NRI protocol to allow eviction to be requested in response to a Synchronize(), too. It was an oversight not to add it.