On 09/05/2016 13:50, Alex Bennée wrote: > > Which locks? tb_lock during tb_find_fast? The problem with that was > > that it slowed down everything a lot, wasn't it? > > Very much so, in the new tree (coming soon) with QHT I was able to > remove the locks from the whole hot-path which means they where only > needed for code generation.
Okay, I'm curious now. :) > > To me, the RCU idea is not really about making tb_flush (the rare case) > > faster; it was more about keeping the rest simple and fast. > > I'm not sure it achieved that as there is added complexity from having > the split buffer and then ensuring you don't double-flush. Agreed. Paolo
