cfq-iosched: IOPS mode for group scheduling and new group_idle tunable
in [Kernel]
|
Prev: [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
Next: [PATCH 2/2] xfs: shrinker should use a per-filesystem scan count
From: Christoph Hellwig on 26 Jul 2010 09:50 On Mon, Jul 26, 2010 at 09:43:29AM -0400, Vivek Goyal wrote: > > Don't know if this is related, but I'm not quite shure if XFS (which I use > > exclusively) uses the jbd/jbd2 journaling layer at all. > > I also don't know. But because this patch is making a difference with your > XFS file system performance, may be it does use. > > CCing Christoph, he can tell us. No, of course XFS doesn't use jbd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vivek Goyal on 26 Jul 2010 09:50 On Sat, Jul 24, 2010 at 10:06:13AM +0200, Heinz Diehl wrote: > On 23.07.2010, Vivek Goyal wrote: > > > Anyway, for fs_mark problem, can you give following patch a try. > > https://patchwork.kernel.org/patch/113061/ > > Ported it to 2.6.35-rc6, and these are my results using the same fs_mark > call as before: > > slice_idle = 0 > > FSUse% Count Size Files/sec App Overhead > 28 1000 65536 241.6 39574 > 28 2000 65536 231.1 39939 > 28 3000 65536 230.4 39722 > 28 4000 65536 243.2 39646 > 28 5000 65536 227.0 39892 > 28 6000 65536 224.1 39555 > 28 7000 65536 228.2 39761 > 28 8000 65536 235.3 39766 > 28 9000 65536 237.3 40518 > 28 10000 65536 225.7 39861 > 28 11000 65536 227.2 39441 > > > slice_idle = 8 > > FSUse% Count Size Files/sec App Overhead > 28 1000 65536 502.2 30545 > 28 2000 65536 407.6 29406 > 28 3000 65536 381.8 30152 > 28 4000 65536 438.1 30038 > 28 5000 65536 447.5 30477 > 28 6000 65536 422.0 29610 > 28 7000 65536 383.1 30327 > 28 8000 65536 415.3 30102 > 28 9000 65536 397.6 31013 > 28 10000 65536 401.4 29201 > 28 11000 65536 408.8 29720 > 28 12000 65536 391.2 29157 > > Huh...there's quite a difference! It's definitely the slice_idle settings > which affect the results here. In this case it is not slice_idle. This patch puts both fsync writer and jbd thread on same service tree. That way once fsync writer is done there is no idling after that and jbd thread almost immediately gets to dispatch requests to disk hence we see improved throughput. > Besides, this patch gives noticeably bad desktop interactivity on my system. > How do you measure it? IOW, are you running something else also on the desktop in the background. Like a heavy writer etc and then measuring how interactive desktop feels? > Don't know if this is related, but I'm not quite shure if XFS (which I use > exclusively) uses the jbd/jbd2 journaling layer at all. I also don't know. But because this patch is making a difference with your XFS file system performance, may be it does use. CCing Christoph, he can tell us. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vivek Goyal on 26 Jul 2010 10:00 On Mon, Jul 26, 2010 at 09:48:18AM -0400, Christoph Hellwig wrote: > On Mon, Jul 26, 2010 at 09:43:29AM -0400, Vivek Goyal wrote: > > > Don't know if this is related, but I'm not quite shure if XFS (which I use > > > exclusively) uses the jbd/jbd2 journaling layer at all. > > > > I also don't know. But because this patch is making a difference with your > > XFS file system performance, may be it does use. > > > > CCing Christoph, he can tell us. > > No, of course XFS doesn't use jbd. Hmm.., interesting. So somewhere WRITE_SYNC idling in CFQ is hurting XFS performance also. This time for some other reason and not jbd/jbd2. Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 26 Jul 2010 10:20 Just curious, what numbers do you see when simply using the deadline I/O scheduler? That's what we recommend for use with XFS anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Heinz Diehl on 26 Jul 2010 12:20
On 26.07.2010, Vivek Goyal wrote: > How do you measure it? IOW, are you running something else also on the > desktop in the background. Like a heavy writer etc and then measuring > how interactive desktop feels? I used Linus' "bigfile torture test" in the background: while : ; do time sh -c "dd if=/dev/zero of=bigfile bs=8M count=256 ; sync; rm bigfile"; done and Theodore Tso's "fsync-tester" to benchmark interactivity. Didn't save any results, wasn't expecting that this could be of any further interest (but can run the tests one more time, if desired). Thanks, Heinz. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |