| To: | Nathan Scott <nathans@xxxxxxx> |
|---|---|
| Subject: | Re: XFS Writes: IOLOCK_EXCL |
| From: | Steve Lord <lord@xxxxxxx> |
| Date: | Thu, 26 Feb 2004 07:27:02 -0600 |
| Cc: | Alex Wun <alexwun@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <20040226040651.GC1177@frodo> |
| References: | <Pine.LNX.4.44.0402240914430.12803-100000@xxxxxxxxxxxxxxxxxxxxxx> <01fa01c3fafa$7c3482d0$9002a8c0@xxxxxxxxxxxxx> <20040225062907.GB1832@frodo> <403CAA00.20502@xxxxxxx> <20040226040651.GC1177@frodo> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla Thunderbird 0.5 (X11/20040208) |
Nathan Scott wrote: I think its always valid to do this (after auditing the callers), but doesn't seem to do "general speedup" - the "usual suspects" benchmarks don't show any improvements anyway. Alex, what was your workload? (you didn't get back to me yet). cheers. I missed the i_sem in nfs, did not look high enough up the stack. Possibly the double flush in there was catching some extra data, which considering we do this under the i_sem is somewhat unlikely. The change would however allow reads to proceed across flushes as the fsync_datawait which matters is now the one in the fsync caller which is not holding any lock a read cares about. Steve |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | TAKE 909327 - fix xfsdump build, FSG QA |
|---|---|
| Next by Date: | Open Source category, Ian Lenzen |
| Previous by Thread: | Re: XFS Writes: IOLOCK_EXCL, Nathan Scott |
| Next by Thread: | Re: XFS Writes: IOLOCK_EXCL, Alex Wun |
| Indexes: | [Date] [Thread] [Top] [All Lists] |