[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalab

From: Sergey Fedorov
Subject: Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table
Date: Fri, 3 Jun 2016 18:19:44 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 03/06/16 12:18, Emilio G. Cota wrote:
> On Sun, May 29, 2016 at 22:52:27 +0300, Sergey Fedorov wrote:
>> I was just wondering if it could be worthwhile to pass a hash function
>> when initializing a QHT. Then we could have variants of qht_insert(),
>> qht_remove() and qht_lookup() which does not require a computed hash
>> value but call the function by themselves. This could make sense since a
>> hash value passed the the functions should always be exactly the same
>> for the same object.
> I considered this when designing the API. I think it's not worth having
> in qht; callers could have their own wrapper to do this though.
> For the only caller of qht that we have so far I don't see this
> as being worth the hassle.
> For instance, we couldn't use the same function for lookups and
> inserts/removals, since the hash function would look like:
> uint32_t hash_func(void *p)
> {
>       TranslationBlock *tb = p;
>       return tb_hash_func(tb->phys_pc, ...);
> }
> But for lookups we don't yet know *tb (that's what we're looking for!).
> All we have is the tb_desc struct that we use for comparisons.

Fair enough.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]