3 ms·
I'm not familiar with bcachefs, so maybe I'm misunderstanding, but the b-tree discussed here also doesn't need to talk locks except for when data is written? I
by foota 2y ago
I'm not familiar with bcachefs, so maybe I'm misunderstanding, but the b-tree discussed here also doesn't need to talk locks except for when data is written?
I'm curious about the per-CPU locks you mention though, do you mean that e.g., nodes are owned by certain CPUs and can only be written from those CPUs (and hence can get away with a CPU local lock?), or something else?
- koverstreet 2y ago> I'm not familiar with bcachefs, so maybe I'm misunderstanding, but the b-tree discussed here also doesn't need to talk locks except for when data is written? Updates to the b-tree in memory require locks too :) > I'm curious about the per-CPU locks you mention though, do you mean that e.g., nodes are owned by certain CPUs and can only be written from those CPUs (and hence can get away with a CPU local lock?), or something else? https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/six.c#n117 https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/... This is the code for btree node locks, as you can see there's a mode where the reader count is stored in a percpu counter. It makes it more expensive to take a write lock, but it means there's zero cacheline contention when just taking read locks (which is by far the common case for interior nodes!).
- foota 2y agoInteresting, I'm not certain, but I think the same thing (e.g., no contention on cache lines) would be achieved through the versions used in optimistic lock coupling, since reads don't need to take a lock?