| To: | Olaf Weber <olaf@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] bump up nr_to_write in xfs_vm_writepage |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Tue, 7 Jul 2009 10:46:01 -0400 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>, linux-mm@xxxxxxxxx, "MASON, CHRISTOPHER" <CHRIS.MASON@xxxxxxxxxx>, xfs mailing list <xfs@xxxxxxxxxxx> |
| In-reply-to: | <bzy8wj0bu72.fsf@xxxxxxxxxxxxxxxxxxxx> |
| References: | <4A4D26C5.9070606@xxxxxxxxxx> <bzyd48cc14d.fsf@xxxxxxxxxxxxxxxxxxxx> <20090707101946.GB1934@xxxxxxxxxxxxx> <bzy8wj0bu72.fsf@xxxxxxxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.18 (2008-05-17) |
On Tue, Jul 07, 2009 at 01:37:05PM +0200, Olaf Weber wrote: > > In theory it should. But given the amazing feedback of the VM people > > on this I'd rather make sure we do get the full HW bandwith on large > > arrays instead of sucking badly and not just wait forever. > > So how do you feel about making the fudge factor tunable? I don't > have a good sense myself of what the value should be, whether the > hard-coded 4 is good enough in general. A tunable means exposing an ABI, which I'd rather not do for a hack like this. If you don't like the number feel free to experiment around with it, SGI should have enough large systems that can be used to test this out. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH, RFC] default to inode64 on 64-bit systems, Eric Sandeen |
|---|---|
| Next by Date: | Re: [PATCH] bump up nr_to_write in xfs_vm_writepage, Chris Mason |
| Previous by Thread: | Re: [PATCH] bump up nr_to_write in xfs_vm_writepage, Olaf Weber |
| Next by Thread: | Re: [PATCH] bump up nr_to_write in xfs_vm_writepage, Chris Mason |
| Indexes: | [Date] [Thread] [Top] [All Lists] |