Re: 2.6.17-...: looong writeouts

[Andrew Morton]

On Sat, 24 Jun 2006 19:15:31 +0400
Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote:

> Immediate problem: from time to time post 2.6.17 kernel [1] decides that it
> really really needs disk.
> 
> 	[kernel compilation goes as usual]
> 	  CC [M]  fs/xfs/xfs_inode.o
> 	[compilation blocks for ~10 seconds, disk LED is red]
> 	[then it continues]
> 
> Again, from time to time saving 2k file makes vi inoperational for same
> period.
> 
> Scheduler is CFQ, fs is reiserfs mounted with noatime, notail. 2.6.17-rc
> and 2.6.17 kernels were OK.
> 
> It occured only several times in 4 hours.
> 
> [1] 2.6.17-95eaa5fa8eb2c345244acd5f65b200b115ae8c65 to be precise
> 
> 
> Probably related problem below:
> 
> During 2.6.17-rc cycle CFQ subjectively became less F.
> 
> 	[   unpacking  ]
> 	[kernel tarball]
> 		.
> 		.
> 		.
> 		.
> 		.
> 		.
> 		.		[:wq on little file]
> 		.
> 		.
> 		.
> 		.
> 		.
> 		.
> 	[              ]
> 
> IIRC, on 2.6.16 that :wq took say 0.5 sec, on late 2.6.17-rc it was
> several times slower. I don't have numbers but it was psychologically
> noticeable, but not BFD.
> 

There have been quite a few CFQ changes.

It'd help if you can come up with a simple test case which others can use
to reproduce this.  Say,

while true
do
	dd if=/dev/zero of=foo bs-1M count=1000 conv=notrunc
done &

versus

time dd if=/dev/zero of=bar bs=16k count=1 conv=fsync

or something like that.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/