Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+bump\s+up\s+nr_to_write\s+in\s+xfs_vm

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+bump\s+up\s+nr_to_write\s+in\s+xfs_vm_writepage\s*$/: 15 ]

Total 15 documents matching your query.

1. [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxx>; Date: Thu, 02 Jul 2009 16:29:41 -0500; Talking w/ someone who had a raid6 of 15 drives on an areca controller, he wondered why he could only get 300MB/s or so out of a streaming buffered write to xfs like so: dd if=/dev/zero of=/mnt/stora; /archives/xfs/2009-07/msg00024.html (7,824 bytes)
2. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>; Date: Sat, 4 Jul 2009 01:51:19 +0200; Amazeing, more than double speed with a one-liner. Do you have more such lines? ;-) Could this be helpful here also: I've just transfered a copy of a directory from our server to a Linux desktop. Not; /archives/xfs/2009-07/msg00032.html (9,374 bytes)
3. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Olaf Weber <olaf@xxxxxxx>; Date: Tue, 07 Jul 2009 11:07:30 +0200; If the nr_to_write calculation really yields a value that is too small, shouldn't it be fixed elsewhere? Otherwise it might make sense to make the fudge factor tunable. -- Olaf Weber SGI Phone: +31(0; /archives/xfs/2009-07/msg00051.html (9,687 bytes)
4. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Tue, 7 Jul 2009 06:19:46 -0400; 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.; /archives/xfs/2009-07/msg00055.html (8,602 bytes)
5. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>; Date: Tue, 7 Jul 2009 19:33:04 +0900 (JST); At least, I agree with Olaf. if you got someone's NAK in past thread, Could you please tell me its url?; /archives/xfs/2009-07/msg00056.html (8,815 bytes)
6. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Tue, 7 Jul 2009 06:44:40 -0400; The previous thread was simply dead-ended and nothing happened.; /archives/xfs/2009-07/msg00061.html (8,561 bytes)
7. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Olaf Weber <olaf@xxxxxxx>; Date: Tue, 07 Jul 2009 13:37:05 +0200; 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. -- Olaf Weber SGI Phone: +3; /archives/xfs/2009-07/msg00062.html (9,670 bytes)
8. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Tue, 7 Jul 2009 10:46:01 -0400; 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 us; /archives/xfs/2009-07/msg00067.html (9,638 bytes)
9. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Chris Mason <chris.mason@xxxxxxxxxx>; Date: Tue, 7 Jul 2009 11:17:20 -0400; I did some quick tests and found some unhappy things ;) On my 5 drive sata array (configured via LVM in a stripeset), dd with O_DIRECT to the block device can stream writes at a healthy 550MB/s. On 2; /archives/xfs/2009-07/msg00068.html (12,234 bytes)
10. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>; Date: Thu, 9 Jul 2009 11:04:32 +0900 (JST); Can you remember this thread subject? sorry, I haven't remember it.; /archives/xfs/2009-07/msg00080.html (9,012 bytes)
11. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Chris Mason <chris.mason@xxxxxxxxxx>; Date: Thu, 9 Jul 2009 09:01:34 -0400; This is the original thread, it did lead to a few different patches going in, but the nr_to_write change wasn't one of them. http://kerneltrap.org/mailarchive/linux-kernel/2008/10/1/3472704/thread -c; /archives/xfs/2009-07/msg00081.html (9,905 bytes)
12. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>; Date: Fri, 10 Jul 2009 16:12:15 +0900 (JST); Thanks good pointer. This thread have multiple interesting discussion. 1. making ext4_write_cache_pages() or modifying write_cache_pages() if he says modifying write_cache_pages() is necessary, I'd; /archives/xfs/2009-07/msg00092.html (11,570 bytes)
13. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Felix Blyakher <felixb@xxxxxxx>; Date: Fri, 24 Jul 2009 00:20:32 -0500; On Thu, Jul 09, 2009 at 11:04:32AM +0900, KOSAKI Motohiro wrote: On Tue, Jul 07, 2009 at 07:33:04PM +0900, KOSAKI Motohiro wrote: At least, I agree with Olaf. if you got someone's NAK in past thread; /archives/xfs/2009-07/msg00240.html (13,331 bytes)
14. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>; Date: Fri, 24 Jul 2009 14:33:02 +0900 (JST); That's ok. you can join mm people :); /archives/xfs/2009-07/msg00241.html (13,867 bytes)
15. Re: [PATCH] bump up nr_to_write in xfs_vm_writepage (score: 1): Author: Chris Mason <chris.mason@xxxxxxxxxx>; Date: Fri, 24 Jul 2009 08:05:19 -0400; It is worth pointing out that Jens Axboe is planning on more feedback controlled knobs as part of pdflush rework. -chris; /archives/xfs/2009-07/msg00247.html (11,399 bytes)

Current List: 1 - 15
Page: [1]