[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 13/14] tb hash: track translated blocks with
From: |
Emilio G. Cota |
Subject: |
Re: [Qemu-devel] [PATCH v4 13/14] tb hash: track translated blocks with qht |
Date: |
Thu, 5 May 2016 17:41:13 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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