4 ms·

kids stuff :) bcachefs uses shared/intent/exclusive locks on nodes, so we only have to take write locks during transaction commit when we're doing the final up

kids stuff :) bcachefs uses shared/intent/exclusive locks on nodes, so we only have to take write locks during transaction commit when we're doing the final update, and percpu read locks for interior nodes (and others). this means that there's basically zero lock contention on interior nodes, or even cacheline bouncing. lock contention only comes up when you've got different keys in the same leaf nodes.

nullpoint420 2y ago
bcachefs may use zero lock contention, but does anyone use bcachefs? (kidding of course, i do) edit: just realized this is _the_ Kent Overstreet! Although my original post was in jest, thank you so much for all your hard work on bcachefs. bcachefs has personally saved me so much time with its copy-on-write functionality, and for that i am very grateful
- foota 2y ago
  My new hobby, labelling my unused code as zero contention, because if it's not running there's zero contention :-)
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 ago
    Interesting, 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?

nullpoint420 2y ago

bcachefs may use zero lock contention, but does anyone use bcachefs? (kidding of course, i do) edit: just realized this is _the_ Kent Overstreet! Although my original post was in jest, thank you so much for all your hard work on bcachefs. bcachefs has personally saved me so much time with its copy-on-write functionality, and for that i am very grateful

foota 2y ago
My new hobby, labelling my unused code as zero contention, because if it's not running there's zero contention :-)

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 ago
  Interesting, 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?