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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux