On Fri, Nov 10, 2006 at 06:36:07AM -0700, Mark Maybee wrote:
> Pawel Jakub Dawidek wrote:
> >On Tue, Nov 07, 2006 at 06:06:48PM -0700, Mark Maybee wrote:
> >>The problem is that in ZFS the vnode holds onto more memory than just
> >>the vnode itself. Its fine to place the vnode on a "free vnodes list"
> >>after a VOP_INACTIVE()... but you need to make sure the you have
> >>"released" the *extra* memory associated with the vnode:
> >> vnode refs a znode (356 bytes + 512 bytes for the phys)
> >> znode refs a dnode (756 bytes + 512-16k for the phys)
> >>So a vnode could be holding up to 17k of data in memory!
> >>
> >>I suggest you free up the znode at VOP_INACTIVE() rather than waiting
> >>until VOP_RECLAIM().
> >How? From What I see znode is freed via zfs_znode_free() called from
> >znode_pageout_func(). I don't think I can just call zfs_znode_free(), as
> >I'm quite sure there are some dependent resources I need to release.
> >Which function should I used for this?
> The callback to the pageout function is triggered by the dmu_buf_rele()
> on the buffer containing the phys portion of the znode. This rele also
> triggers the freeing of all the other memory associated with the znode.
>
> In the current Solaris bits, the rele happens in zfs_zinactive().
Ok, I also call dmu_buf_rele() from zfs_zinactive(), but I don't see
pageout beeing called right after zfs_zinactive().
In dmu_buf_rele() function I've such data (this is on simple
'touch /tank/foo'):
holds = 1
db->db_dirtycnt = 1
db->db_level = 0
db->db_d.db_immediate_evict = 0
Is it the same in Solaris on 'touch /tank/foo' for dmu_buf_rele() called
from zfs_zinactive()?
PS. I'm sorry for wasting your time, I could check it be myself with
dtrace, but I decided to reinstall my Solaris installation and now it
seems I've some hardware problems, so I need to find another box to
install Solaris on, which will allow me to do such comparsions by myself.
--
Pawel Jakub Dawidek http://www.wheel.pl
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20061110/411d4f27/attachment.bin>
