Re: [PATCH v3] 9pfs: use GHashTable for fid table

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Donnerstag, 8. September 2022 13:23:53 CEST Linus Heckemann wrote:
> The previous implementation would iterate over the fid table for
> lookup operations, resulting in an operation with O(n) complexity on
> the number of open files and poor cache locality -- for every open,
> stat, read, write, etc operation.
> 
> This change uses a hashtable for this instead, significantly improving
> the performance of the 9p filesystem. The runtime of NixOS's simple
> installer test, which copies ~122k files totalling ~1.8GiB from 9p,
> decreased by a factor of about 10.
> 
> Signed-off-by: Linus Heckemann <git@sphalerite.org>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Reviewed-by: Greg Kurz <groug@kaod.org>
> ---

Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next

I retained the BUG_ON() in get_fid(), Greg had a point there that continuing 
to work on a clunked fid would still be a bug.

I also added the suggested TODO comment for g_hash_table_steal_extended(), the 
actual change would be outside the scope of this patch.

And finally I gave this patch a whirl, and what can I say: that's just sick! 
Compiling sources with 9p is boosted by around factor 6..7 here! And running 
9p as root fs also no longer feels sluggish as before. I mean I knew that this 
fid list traversal performance issue existed and had it on my TODO list, but 
the actual impact exceeded my expectation by far.

Thanks!

Best regards,
Christian Schoenebeck