[Top] [All Lists]

Re: [PATCH 4/6] xfs: introduce background inode reclaim work

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 4/6] xfs: introduce background inode reclaim work
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 10 Mar 2011 12:40:54 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1299715529-11026-5-git-send-email-david@xxxxxxxxxxxxx>
References: <1299715529-11026-1-git-send-email-david@xxxxxxxxxxxxx> <1299715529-11026-5-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
Why do we still keep the inode reclaim in the syncer work?  If we
already have this one doing it I don't think we need it there as well.

>  /*
> + * Queue a new inode reclaim pass if there isn't one already in progress.
> + * Wait for completion of the flush if necessary.

No, it doesn't wait ever.

> + */
> +static void
> +xfs_syncd_queue_reclaim(
> +     struct xfs_mount        *mp)
> +{
> +     queue_delayed_work(xfs_syncd_wq, &mp->m_reclaim_work,
> +                     xfs_syncd_centisecs / 5 * msecs_to_jiffies(10));

What explanation is there for the magic 5?  E.g. why do we neeed to run
it exactly 5 times as often as the normal sync work? Should it have it's
own tunable?  And isn't ever 6 seconds by default a little often on
systems trying to saver power, especiall if there aren't any inodes to
reclaim?  Should we trigger starting this work off having reclaimable
inodes tagged in the radix tree?

> +     /* first unpin all the dirty and stale inodes. */
> +     xfs_log_force(mp, XFS_LOG_SYNC);

So we force out the log every 6 seconds.  That's a lot more often than
most other filesystem and might have adverse performance impact.

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