[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 1/3] xfs: introduce an allocation workqueue
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 19 Jul 2011 13:14:29 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110719020214.GB4259@xxxxxxxxxxxxx>
References: <1310960989-10284-1-git-send-email-david@xxxxxxxxxxxxx> <1310960989-10284-2-git-send-email-david@xxxxxxxxxxxxx> <20110718160046.GA14094@xxxxxxxxxxxxx> <20110719012450.GG30254@dastard> <20110719020214.GB4259@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Jul 18, 2011 at 10:02:14PM -0400, Christoph Hellwig wrote:
> 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.

What do you want me to run? I don't have any particularly high IOP
hardware here, but I might be able to do something that just hits
the BBWC....


Dave Chinner

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