-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core: plumbing to support numa aware scheduling #18681
Conversation
36a4516
to
290960a
Compare
ae294ab
to
613df11
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great @shoenig! I've left some questions about a few bits I'm unsure of.
// Compatibility will translate the LegacyNodeCpuResources into NodeProcessor | ||
// Resources, or the other way around as needed. | ||
func (n *NodeResources) Compatibility() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When servers are upgraded before clients, the old clients will be transmitting the old fingerprints but that only happens if they have a new fingerprint to send (not on heartbeat). And the scheduler won't typically call Copy
or Merge
, so if we upgrade and then dequeue an eval that reads an old node before we read that new fingerprint then the node won't have these compatibility updates.
So maybe we could call this from FSM restore, so that we immediately fix-up anything that's in Raft. I think that would also let us move this into a Canonicalize
method on Node
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nice catch; added a call to Compatibility()
inside Node.Canonicalize()
in e79311c
Handle the case where an upgraded server dequeus an evaluation before a client triggers a new fingerprint - which would be needed to cause the compatibility fix to run. By running the compat fix on restore the server will immediately have the compatible pseudo topology to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Nice work!
This PR contains the bulk of implementation for NUMA-aware scheduling, a feature coming for Nomad Enterprise 1.7. See NMD-187 (internal) for details.
The CE specific bits are in
nomad/job_endpoint_hook_numa_ce.go
andscheduler/numa_ce.go
.Note: e2e, documentation, changelog, etc. will be in followup PRs.
Overview of changes
task.resources.numa.affinity = <string>
NodeResources
CpuResources
is removed except for client<->server upgrade compatibilityresources.numa
in CEresources.numa
mock
package now providesMockBasicTopology()
to be used instead of manually setting cpu resources in testscoreSelector.Select()
(for CE here) for choosing cpu cores in the same way as they were previouslyRankNode