On Sun, Oct 13, 2013 at 12:21:05AM +0100, Saso Kiselkov wrote: > The performance gains from this are pretty substantial in my testing. > The time needed to rebuild 93 GB worth of ARC buffers consisting of a > mixture of 128k and 8k blocks (total number of ARC buffers: 6.4 million, > or ~15.4k average block size) decreased from ~50s to about 9.5s (with a > small portion of that being physical L2ARC read latency).
Where exactly did the performance improvement come from? I'm not doubting the work, I'm just curious. Is it faster because the hash chains are shorter now (i.e. less "work" done under bucket lock leading to better concurrency)? Or something else? If the improvement does comes indeed come from increased concurrency due to shorter hash chains, I'd imagine this would benefit workloads other than L2ARC rebuild times. As such, It would be nice to have a before/after workload showing the better performance numbers without having to rely on the persistent L2ARC changes. Especially since I see this work being split into its own independent patch, as posted to the open-zfs list. > > I apologize for this long litany of an email and look forward to your > comments and reviews. Actually, I think it was useful context. -- Cheers, Prakash > > Cheers, > -- > Saso > > > ------------------------------------------- > illumos-zfs > Archives: https://www.listbox.com/member/archive/182191/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182191/23963346-4bb55813 > Modify Your Subscription: > https://www.listbox.com/member/?member_id=23963346&id_secret=23963346-89c22f02 > Powered by Listbox: http://www.listbox.com _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
