| 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. |
| Previous by Date: | Re: [PATCH 1/4] xfs: use a cursor for bulk AIL insertion, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 3/3] xfs: flush the CIL via a workqueue, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH 1/3] xfs: introduce an allocation workqueue, Dave Chinner |
| Next by Thread: | Re: [PATCH 1/3] xfs: introduce an allocation workqueue, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |