On Sat, 24 Jun 2006 19:15:31 +0400
Alexey Dobriyan <[email protected]> wrote:
> Immediate problem: from time to time post 2.6.17 kernel  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
> 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.
>  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,
dd if=/dev/zero of=foo bs-1M count=1000 conv=notrunc
time dd if=/dev/zero of=bar bs=16k count=1 conv=fsync
or something like that.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]