From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anTDF-0003Gk-ON for qemu-devel@nongnu.org; Tue, 05 Apr 2016 11:48:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anTDD-0003Ti-0o for qemu-devel@nongnu.org; Tue, 05 Apr 2016 11:48:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anTDC-0003Te-RG for qemu-devel@nongnu.org; Tue, 05 Apr 2016 11:48:14 -0400 References: <1459834253-8291-1-git-send-email-cota@braap.org> <1459834253-8291-8-git-send-email-cota@braap.org> <5703DCB7.50302@twiddle.net> From: Paolo Bonzini Message-ID: <5703DE37.3080306@redhat.com> Date: Tue, 5 Apr 2016 17:48:07 +0200 MIME-Version: 1.0 In-Reply-To: <5703DCB7.50302@twiddle.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/10] tb hash: hash phys_pc, pc, and flags with xxhash List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , "Emilio G. Cota" , QEMU Developers , MTTCG Devel Cc: Peter Maydell , Sergey Fedorov , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Peter Crosthwaite On 05/04/2016 17:41, Richard Henderson wrote: > >> +static inline >> +uint32_t tb_hash_func(tb_page_addr_t phys_pc, target_ulong pc, >> uint64_t flags) >> { >> - return (pc >> 2) & (CODE_GEN_PHYS_HASH_SIZE - 1); >> + struct key { >> + tb_page_addr_t phys_pc; >> + target_ulong pc; >> + uint64_t flags; > > The flags field should be uint32_t, not uint64_t. > See its definition in TranslationBlock. > >> + } QEMU_PACKED k; >> + unsigned int hash; >> + >> + k.phys_pc = phys_pc; >> + k.pc = pc; >> + k.flags = flags; >> + hash = qemu_xxh32((uint32_t *)&k, sizeof(k) / sizeof(uint32_t), 1); > > I'm less than happy about putting data into a struct and hashing that > memory. Why don't you just take the ideas from xxh32/xxh64 and perform > the hash directly right here? > > In particular, you've 3 data elements here, a maximum of 5 32-bit words, > thus the loop within xxh32 will never roll, so it's mostly dead code. I think it's fine to use the struct. The exact size of the struct varies from 3 to 5 32-bit words, so it's hard to write nice size-dependent code for the hash. Paolo