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 [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 [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]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
