Subject: UP/SMP and atomic ops
To: None <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 11/28/2007 19:43:10
I see that the new atomic ops that have been added to kernel, are
patched to behave like non-atomic ops on UP kernels.
Even for UP systems there are cases where we want atomic memory operations:
- read/write to in-memory structres shared with devices. Some device
controllers really behaves like a CPU. I know that reordered
load/store can cause issues with esiop, and I suspect the occasional timeouts
I've noticed can come from this. The lack of appropriate MI interface
to fix this has always bothered be, and I think it's a real issue.
- read-write to data shared with the hypervisor or another domain in Xen.
A guest may be UP, although the hardware it's running on is SMP.
Domain0 can eventually know the harware's number of CPUs but I'm
not sure this information is available to guests (and with migration, this
So I think we need to class of atomic ops:
- ops for data private to (eventually virtual) CPUs, and which can be patched
when we know that the system has only one CPU
- ops for data used out of the CPUs and that will never be patched.
Manuel Bouyer <email@example.com>
NetBSD: 26 ans d'experience feront toujours la difference