The patch itself seems to be "purely opportunistic" :), hence two questions: 1. How does it impact prefetch efficiency? 2. If it does impact prefetch significantly, is there any other, less destructive, locking approach?
Regards, Andrey On Tue, Aug 18, 2009 at 2:52 AM, Kip Macy<kmacy at freebsd.org> wrote: > I have made a number of what I would call non-structural changes to > ZFS (no changes to file system semantics or space allocation) to > improve the performance of ZFS, as imported in to FreeBSD, in my > client's environment. Pawel Dawidek has asked that I try to get my > changes pushed upstream to minimize the pain involved in importing > future ZFS versions. > > Among other things I found that there was a great deal of lock > contention in prefetch. In light of the fact that prefetch is a purely > opportunistic operation, it does not make sense to me to delay > productive work in order to issue a prefetch request. In the following > patch I have changed the locking operations to be 'trylock's, failing > the operation if the lock acquisition does not succeed. > > http://people.freebsd.org/~kmacy/dmu_zfetch_trylock.patch > > Constructive criticism, feedback, etc. is welcome. > > > Thanks, > Kip > > > -- > When harsh accusations depart too far from the truth, they leave > bitter consequences. > --Tacitus > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code >
