Fedora 39 Looks To Boost vm.max_map_count To Help Windows Games With Steam Play

[NateHubbard]

What on earth are those games doing that they need tens of thousands of separate mappings?

Requesting more than that, apparently.

[Teggs]

I noticed when I looked into Nobara that they listed this change: vm.max_map_count = 16777216 set by default for Star Citizen

One less tweak for them to make I guess.

[pieman]

are there downsides to raising this limit?

[horizonbrave]

Good job, but now give us some video codecs out of the box or please consider moving your offices in a less silly country

[archkde]

Exactly. Does every malloc trigger this?

Unless you're running the efence debugging tool, no. Normal allocators only directly mmap large allocations (usually at some tens to hundreds of kilobytes) and satisfy smaller allocation from a pool (either brk or a relatively small number of large mmaps). Maybe they are mmapping a lot of small files.

[mdedetrich]

What on earth are those games doing that they need tens of thousands of separate mappings?

Games like this are some of the largest pieces of non trivial software you can come up with, aside from OS's/browsers so its hardly surprising that some of them do this kind of thing.

[direc85]

The answer is somewhere between 65535 and Graham's Number, uh, I mean INTMAX - 5.

[szymon_g]

cant they just release a patch that will change it in currently used 37/38 version? why wait till 39?

[arQon]

Games like this are some of the largest pieces of non trivial software you can come up with, aside from OS's/browsers so its hardly surprising that some of them do this kind of thing.

True, but 50K+ is WAY beyond almost any genuine purpose I can think of. I've used mmap to deal with huge files back in the days of limited RAM, as basically a sensible way to offload cache management for files that needed to STAY open, but games are the exact opposite of that case. The only way you even get close to the current limit is by using mmap as a replacement for open and leaking the handles.

I suspect it's some weird aspect of the DirectStorage model, i.e. just doing exactly that: you open literally EVERY asset concurrently with completion callbacks, and DS reorders the reads to minimize decompressor re-inits and/or re-reads of shared blocks, with the handles only being closed async a few seconds later.

[avis]

While Fedora's default of 65,530 for vm.max_map_count matches that of many other OS defaults, SteamOS Ships with a value of 2147483642 (MAX_INT - 5).

It's not Fedora's default, it's the kernel's default:

https://github.com/torvalds/linux/blob/master/include/linux/mm.h#L203

https://github.com/torvalds/linux/blob/master/include/vdso/limits.h#L5