xfs
[Top] [All Lists]

Re: [PATCH 2/2] xfs: reclaim all inodes by background tree walks

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/2] xfs: reclaim all inodes by background tree walks
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 8 Jan 2010 21:43:48 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20100108102408.GB16640@xxxxxxxxxxxxx>
References: <1262819125-27083-1-git-send-email-david@xxxxxxxxxxxxx> <1262819125-27083-3-git-send-email-david@xxxxxxxxxxxxx> <20100108102408.GB16640@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Fri, Jan 08, 2010 at 05:24:08AM -0500, Christoph Hellwig wrote:
> 
> Looks safe to me.  I wonder whaimpact leaving the inodes around for
> longer has to memory usage for inode heavy workloads, though.

In terms of wall time, nothing I can measure, but it seems to reduce
system time slightly. My main concern is memory pressure - maybe it
needs a shrinker registered to reclaim inodes immediately rather
than waiting for the next xfsssyncd run...

> >  unlock_and_requeue:
> > +   /*
> > +    * We could return EAGAIN here to make reclaim rescan the inode tree in
> > +    * a short while. However, this just burns CPU time scanning the tree
> > +    * waiting for IO to complete and xfssyncd never goes back to the idle
> > +    * state. Instead, return 0 to let the next scheduled background reclaim
> > +    * attempt to reclaim the inode again.
> > +    */
> >     xfs_iflags_clear(ip, XFS_IRECLAIM);
> >     xfs_iunlock(ip, XFS_ILOCK_EXCL);
> > -   return EAGAIN;
> > +   return 0;
> 
> This is an unrelated change and should be a patch of it's own.

Yup.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>