On Tue, May 17, 2016 at 20:47:52 +0300, Sergey Fedorov wrote:
> On 14/05/16 06:34, Emilio G. Cota wrote:
> > For some workloads such as arm bootup, tb_phys_hash is performance-critical.
> > The is due to the high frequency of accesses to the hash table, originated
> > by (frequent) TLB flushes that wipe out the cpu-private tb_jmp_cache's.
> > More info:
> > https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg05098.html
> >
> > To dig further into this I modified an arm image booting debian jessie to
> > immediately shut down after boot. Analysis revealed that quite a bit of time
> > is unnecessarily spent in tb_phys_hash: the cause is poor hashing that
> > results in very uneven loading of chains in the hash table's buckets;
> > the longest observed chain had ~550 elements.
> >
> > The appended addresses this with two changes:
>
> Does "the appended" means "this patch"? Sorry, I've just never seen such
> expression before...
Yes, in this context a patch is _appended_ to the (long-ish) discussion.
(snip)
> > -static inline unsigned int tb_phys_hash_func(tb_page_addr_t pc)
> > +static inline
> > +uint32_t tb_hash_func(tb_page_addr_t phys_pc, target_ulong pc, int flags)
>
> Nitpicking: now 'flags' is of uint32_t type.
I've changed this in my tree -- thanks!
Emilio
