Skip to content

bpf: lru: adjust free target to avoid global table starvation #9131

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

Closed

Conversation

kernel-patches-daemon-bpf[bot]
Copy link

Pull request for series with
subject: bpf: lru: adjust free target to avoid global table starvation
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: f66b4aa
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: a633dab
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: 85cd83f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: f5527f0
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: bd07bd1
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555
version: 1

@kernel-patches-daemon-bpf
Copy link
Author

Upstream branch: cd7312a
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=972555
version: 1

BPF_MAP_TYPE_LRU_HASH can recycle most recent elements well before the
map is full, due to percpu reservations and force shrink before
neighbor stealing. Once a CPU is unable to borrow from the global map,
it will once steal one elem from a neighbor and after that each time
flush this one element to the global list and immediately recycle it.

Batch value LOCAL_FREE_TARGET (128) will exhaust a 10K element map
with 79 CPUs. CPU 79 will observe this behavior even while its
neighbors hold 78 * 127 + 1 * 15 == 9921 free elements (99%).

CPUs need not be active concurrently. The issue can appear with
affinity migration, e.g., irqbalance. Each CPU can reserve and then
hold onto its 128 elements indefinitely.

Avoid global list exhaustion by limiting aggregate percpu caches to
half of map size, by adjusting LOCAL_FREE_TARGET based on cpu count.
This change has no effect on sufficiently large tables.

Similar to LOCAL_NR_SCANS and lru->nr_scans, introduce a map variable
lru->free_target. The extra field fits in a hole in struct bpf_lru.
The cacheline is already warm where read in the hot path. The field is
only accessed with the lru lock held.

The tests are updated to pass. Test comments are extensive: updating
those is left for a v2 if the approach is considered ok.

Signed-off-by: Willem de Bruijn <[email protected]>
@kernel-patches-daemon-bpf
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=972555 expired. Closing PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant