On Wed, May 04, 2016 at 07:22:16 -1000, Richard Henderson wrote: > On 05/04/2016 05:36 AM, Emilio G. Cota wrote: > >BTW in the last couple of days I did some more work beyond v4: > > > >- Added a benchmark (not a correctness test) to measure parallel > > performance of QHT (recall that test/qht-test is sequential.) > > > >- Added support for concurrent insertions as long as they're not to the > > same bucket, thus getting rid of the "external lock" requirement. > > This is not really needed for MTTCG because all insertions are supposed > > to be serialized by tb_lock; however, the feature (1) has no negative > > performance impact (just adds an unlikely() branch after lock acquisition > > on insertions/removals) and (2) could be useful for future (parallel) > > users of qht. > > > >Should I send this work as follow-up patches to v4 to ease review, or > >should I send a v5 with them merged in? > > Let's handle these as follow-on, since we've already got multiple R-b tags > for v4.
OK, will submit the modifications next week. BTW Benchmarking with the new test is giving me some interesting results. For instance, I'm measuring a 5% lookup latency reduction (single-threaded throughput goes from 45.84 to 48.41 M lookups/s) if I remove support in qht for MRU promotions. This is tempting me to just kill the feature, since resizing works very well. And it would save ~90 lines of code. Is anyone against this? Thanks, Emilio