[Top] [All Lists]

Re: [PATCH 1/3] xfs: introduce an allocation workqueue

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 1/3] xfs: introduce an allocation workqueue
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 18 Jul 2011 22:02:14 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20110719012450.GG30254@dastard>
References: <1310960989-10284-1-git-send-email-david@xxxxxxxxxxxxx> <1310960989-10284-2-git-send-email-david@xxxxxxxxxxxxx> <20110718160046.GA14094@xxxxxxxxxxxxx> <20110719012450.GG30254@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jul 19, 2011 at 11:24:50AM +1000, Dave Chinner wrote:
> Honestly, I'd prefer not to do that because it's a slippery slope.
> I've got plenty more "do stuff in the background via workqueues"
> patches lined up, so if we start adding knobs/mount options to turn
> each of them off "just in case there's an issue".
> So far I haven't found any issues at all and I've been running this
> split allocation stack like this in -all- my performance testing for
> the past 2-3 months. I know that is not conclusive, but if the
> bechmarks I've been using to improve XFS performance over the past
> 18 months don't show regressions, that's fairly indicative of the
> fact that most workloads won't even notice the change....

Maybe.  One thing I'd like to see is stuff like high-iop direct or
O_SYNC I/O that actually calls the allocator.

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