Pawel Jakub Dawidek wrote:
> 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()?

This looks fine.  Note that the db_immediate_evict == 0 means that you
will probably *not* see a callback to the pageout function immediately.
This is the general case.  We hold onto the znode (and related memory)
until the associated disk blocks are evicted from the cache (arc).  The
cache is likely to hold onto that data until either:
        - we encounter memory shortage, and so reduce the cache size
        - we read new data into the cache, and evict this data to
          make space for it.

-Mark

Reply via email to