← Back to context

Comment by masklinn

2 years ago

The article is extremely confusingly worded, sometimes close to nonsensical (epyc as baseline? In what damn world?), and definitely clickbaity.

From what I understand what was limited to 8 cores is the scaling of the preemption delay (min_granularity / min_slice). Again from what I understand that what this is is the window during which a process can not be preempted, so this is only relevant when the scheduler has more tasks to run than available slices (the system is heavily / over - loaded).

I would assume well-administered systems where this would be relevant:

1. Are not overloaded

2. Have the important tasks pinned to avoid migrations

3. Have priorities configured to avoid preempting / descheduling their primary workloads

As such, on a well-administered system this would mostly translate to possibly over-pre-empting low-priority tasks (and most likely not pre-empting anything because the machine is configured with capacity for those ancillary / transient low priority tasks). This may show up during transient overloads, and worsen an already bad situation, but it probably wouldn’t show up during normal operations.

It also doesn’t seem accidental, the maintainers literally slapped an `min(8, …)` on there, so they explicitly designed the scaling to have an upper bound. Maybe it’s a mistake, maybe it’s too low, maybe it should be a tunable, but I’d think it makes sense to not allow the preemption delay to grow infinitely.