Hi all, can I get a review of version #2 for this small fix?
Webrev: http://cr.opensolaris.org/~pavelf/6897605-xattr-v2 Thanks, Pavel On 11/17/09 19:05, Pavel Filipensky wrote: > Hi All, > > I have modified the fix a little bit - can I get a review for that? > > Webrev: > http://cr.opensolaris.org/~pavelf/6897605-xattr-v2 > > It will skip VN_RELE(xattr) only if the r_hasq is same. The advantage > is that more memory is freed.Originally, I was resistant to use the > value of r_hasq - since it should be a private data of lower layer > and opaque to the nfs_reclaim code, but nfs4_active_reclaim() is > already aware of the implementation details of rnode table. > > Cheers, > Pavel > > > > On 11/09/09 14:22, Calum Mackay wrote: > > On 09/11/09 13:06, Frank Batschulat (Home) wrote: > >>> 2) introduce VN_RELE_ASYNC(xattr) > >>> pros: - more memory is reclaimed > >>> cons: - slower code (extra work when the system is low on memory) > >>> - adding a new code - need to create a new taskq (pool?) > >> > >> yepp, we'd have to create a new taskq as well, we probaly do not want > >> to use > >> the system taskq here. > > > > yup. > > > > We looked at this a year or two ago, to work-around an issue where the > > network layer was calling into VFS from interrupt context, where we > > run into problems if we end up doing rnode inactivation. > > > > It opened up a larger can of worms (e.g taskq setup from interrupt > > context) than we were trying to fix, however, and since calling into > > VFS from interrupt is poor practice in any case, we decided that > > adding the async rele wasn't really worth the effort, at least in that > > case. > > > > cheers, > > c. > > _______________________________________________ > nfs-discuss mailing list > nfs-discuss at opensolaris.org > _______________________________________________ > nfs-discuss mailing list > nfs-discuss at opensolaris.org