From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Xu <peterx@redhat.com>, Jason Wang <jasowang@redhat.com>,
mst@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH for 8.1] intel_iommu: refine iotlb hash calculation
Date: Thu, 13 Apr 2023 10:42:48 +0100 [thread overview]
Message-ID: <878rewcdf6.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA8TB65xkv2+ZVdY0jYdEPU-uAc+twK5=eWYzkwZYbkhmQ@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On Wed, 12 Apr 2023 at 09:40, Alex Bennée <alex.bennee@linaro.org> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > Whoops, hadn't noticed that guint type... (glib's
>> > g_int64_hash()'s approach to this is to XOR the top
>> > 32 bits with the bottom 32 bits to produce the 32-bit
>> > hash value.)
>>
>> This is less of a hash and more just concatting a bunch of fields. BTW
>> if the glib built-in hash isn't suitable we also have the qemu_xxhash()
>> functions which claim a good distribution of values and we use in a
>> number of places throughout the code.
>
> Is that really necessary? If glib doesn't do anything complex
> for "my keys are just integers" I don't see that we need to
> do anything complex for "my keys are a handful of integers".
> glib does do a bit on its end to counteract suboptimal hash functions:
>
> https://github.com/GNOME/glib/blob/main/glib/ghash.c#L429
>
> static inline guint
> g_hash_table_hash_to_index (GHashTable *hash_table, guint hash)
> {
> /* Multiply the hash by a small prime before applying the modulo. This
> * prevents the table from becoming densely packed, even with a poor hash
> * function. A densely packed table would have poor performance on
> * workloads with many failed lookups or a high degree of churn. */
> return (hash * 11) % hash_table->mod;
> }
>
> I figure if glib thought that users of hash tables should be
> doing more complex stuff then they would (a) provide helpers
> for that and (b) call it out in the docs. They don't do either.
Ahh I didn't realise glib was adding extra steps (although I guess it
makes sense if it is resizing its tables) or that their default hash
functions where so basic.
The original primary user of the qemu_xxhash functions is QHT which has
to manage its own tables so relies more on having a well distributed
hash function.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
prev parent reply other threads:[~2023-04-13 9:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 3:32 [PATCH for 8.1] intel_iommu: refine iotlb hash calculation Jason Wang
2023-04-11 13:34 ` Peter Maydell
2023-04-11 14:14 ` Peter Xu
2023-04-11 14:30 ` Peter Maydell
2023-04-11 14:44 ` Peter Xu
2023-04-12 6:52 ` Jason Wang
2023-04-12 8:22 ` Alex Bennée
2023-04-12 21:06 ` Peter Maydell
2023-04-13 9:42 ` Alex Bennée [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rewcdf6.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.