TIL about split lock detection.

Wow, that's mean.

I mean, yes, don't do that. But also, I think there are better ways to help out userspace than massive punishment.

@gfxstrand What is split lock detection ?

(Where can I learn about it ?)

@Sobex @gfxstrand atomics that span a cacheline because they're badly aligned

x86 supports it, but it's super expensive because a bus lock instead of usual cacheline coherency protocols. most other architectures just give you an exception and you're dead

it's so expensive for x86 that there's plans to remove it, hence the split lock detection. and it's getting more expensive every year due to ever increasing cpu core counts

@sima Those plans are going to make hell for users with apps that have split lock bugs in them.

phoronix.com/news/Linux-Splitl

Not that keeping them working forever is a good plan either. But it's gonna be hell on users if they just pull it out of the CPU and start throwing exceptions with no option for an emulation mode you can turn on.

Really, allowing unaligned uint64_t on x86 was a mistake.

@Sobex

@gfxstrand @Sobex it sucks

maybe there's going to be an opt-in for desktop backwards compat because games or something like that, where it's probably acceptable to take the system wide performance hit

@sima @gfxstrand @Sobex I'm sorry if that a dumb question because i know nothing of kernel development but is there no way to have a fake split lock for the app and then use a better locking system behind ? :blobcatcoffee:

@Nulhomme @gfxstrand @Sobex you could implement it in the kernel by zapping all pagetable entries userspace has pointing at that memory, doing the atomic while holding the folio lock (or two folio locks, if it also spawns a page boundary).

dead slow, but doable, maybe less worse than allowing it in hw. I really don't know what the tradeoffs are here

@sima @Nulhomme @gfxstrand @Sobex are we talking copying the memory pages, holding the folio lock while we update the page tables. Or holding the locks while doing the writes? Honestly hard for me to tell what would be cheaper, probably would have to test both.

@sima @Nulhomme @gfxstrand @Sobex assuming we can update the page tables atomicaly. Copying the pages should have no impact on a read only thread, at the cost of copying at most 8k assuming small pages. I don't know how we would deal with writers, other then let the last writer win and ignore all writers in progress.

@ekg @Nulhomme @gfxstrand @Sobex you don't need to copy the entire page, just emulate the atomic instruction after having removed all userspace pagetable entries, to make sure the access is atomic

the expensive part is removing the pagetable entries and invalidating tlbs

Follow

@sima I also realised the slightly bigger problem that copying the page would lead to write consolidation problems.

Assuming we have some fine grain control, couldn't we invalidate the cash lines remotely? Assuming hardware support.

· Librem Social · 0 · 0 · 0
Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml