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 <g...@sphalerite.org> > Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org> > Reviewed-by: Greg Kurz <gr...@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
