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

Reply via email to