Concurrent page-fault handling with per-VMA locks [LWN.net]

Concurrent page-fault handling with per-VMA locks

Posted Sep 5, 2022 21:05 UTC (Mon) by Homer512 (subscriber, #85295)
In reply to: Concurrent page-fault handling with per-VMA locks by developer122
Parent article: Concurrent page-fault handling with per-VMA locks

Do we even care about rollover? If the sequence number is 64 bit, a 5 GHz machine cannot roll it over in over 100 years, even if it could increment the number once per clock cycle.

to post comments

Concurrent page-fault handling with per-VMA locks

Posted Sep 6, 2022 15:31 UTC (Tue) by calumapplepie (guest, #143655) [Link] (6 responses)

Hmm, good point... the downside would be memory consumption. 64-bit sequence numbers would increase the size of every vma_struct by about 5% (by my estimate of scanning the code). `sudo cat /proc/*/maps | wc` tells me I have 146,368 VMAs right now on my laptop; 8 extra bytes each would add up to around a megabyte, which is fairly small, especially considering what I have running right now (Firefox, Chrome, Libreoffice, Calibre, and Evolution, plus a few other apps). That being said, I remember seeing an article on here about an effort to share vma_struct instances between processes, so there might some group that's seeing much larger numbers.

Concurrent page-fault handling with per-VMA locks

Posted Sep 6, 2022 16:20 UTC (Tue) by adobriyan (subscriber, #30858) [Link] (1 responses)

> 64-bit sequence numbers would increase the size of every vma_struct by about 5% (by my estimate of scanning the code)

VMAs are 200 bytes (on my F35 system) and on most systems they will be allocated from kmalloc-256,
so there is plenty of space.

Concurrent page-fault handling with per-VMA locks

Posted Sep 6, 2022 16:27 UTC (Tue) by adobriyan (subscriber, #30858) [Link]

Hmm... Fedora disabled SLAB merging.

Concurrent page-fault handling with per-VMA locks

Posted Sep 6, 2022 16:35 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

> Hmm, good point... the downside would be memory consumption. 64-bit sequence numbers would increase the size of every vma_struct by about 5% (by my estimate of scanning the code).

Could you make the sequence number include the pid?

What are the chances of a 16-bit rolling number concatenated with the low order 16-bit pid as your sequence number colliding?

Cheers,
Wol

Concurrent page-fault handling with per-VMA locks

Posted Sep 6, 2022 20:42 UTC (Tue) by WolfWings (subscriber, #56790) [Link] (1 responses)

...hasn't the PID been quite a bit larger than 16-bit for some time now? Just software limited to only use 16-bit PIDs by default for compatibility?

Concurrent page-fault handling with per-VMA locks

Posted Sep 7, 2022 6:24 UTC (Wed) by Wol (subscriber, #4433) [Link]

I know. Which is why I said use the low-order 16 bits ...

Cheers,
Wol

Concurrent page-fault handling with per-VMA locks

Posted Sep 6, 2022 20:48 UTC (Tue) by Homer512 (subscriber, #85295) [Link]

True. All in all, corbet's answer is probably the better one: A false-positive due to rollover is harmless and just results in semi-random slow-paths. So we might even use a tiny 8 bit counter if it makes struct packing better.