LWN: Comments on "Mitigating vmap lock contention" https://lwn.net/Articles/932396/ This is a special feed containing comments posted to the individual LWN article titled "Mitigating vmap lock contention". en-us Wed, 22 Oct 2025 11:09:25 +0000 Wed, 22 Oct 2025 11:09:25 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Mitigating vmap lock contention https://lwn.net/Articles/933262/ https://lwn.net/Articles/933262/ kazer <div class="FormattedComment"> To me it seems like video playback is an example, not the only case at all.<br> <p> Regarding video playback, can you tell what happens during streaming when bitrate changes and so forth? To me there is plenty of variation that needs to be accounted for..<br> <p> </div> Tue, 30 May 2023 12:58:56 +0000 Mitigating vmap lock contention https://lwn.net/Articles/933225/ https://lwn.net/Articles/933225/ sima <div class="FormattedComment"> So yeah if this is for video playback only, that's a userspace/driver issue, not a vmap issue. Of all gpu workloads video codec really should be the most predictable, allocate all buffers you need upfront and then recycle. If there's enough reallocations during playback to matter something is really busted.<br> </div> Tue, 30 May 2023 10:13:13 +0000 Mitigating vmap lock contention https://lwn.net/Articles/933180/ https://lwn.net/Articles/933180/ wens <div class="FormattedComment"> We hit this bottleneck hard. Our service involves a large number of incoming SSH connections. The bottleneck happens in two places: a) per-process kernel stack (if VMAP_STACK is enabled) allocation and b) pty (always allocated through vmalloc) allocation. In the end we rewrote a suitable SSH backend, instead of using OpenSSH.<br> </div> Mon, 29 May 2023 14:56:26 +0000