Comment 204 for bug 620074

<email address hidden> schreef:
> http://bugzilla.kernel.org/show_bug.cgi?id=12309
>
>
>
>
>
> ------- Comment #189 from <email address hidden> 2009-03-01 01:26
> -------
> (In reply to comment #134)
>
>> Hi.
>>
>> On my laptop(Core2Duo 1.6 ghz) I run my gentoo kernel 2.6.28-gentoo.
>> I didn't have any problems with latency.
>>
>> If I run "dd if=/dev/zero of=file bs=1M count=2048" or "dd if=/dev/zero
>> of=/tmp/test bs=1M count=1M" (I tried to run it as user and also as root),
>> my
>> system works well and I can start firefox, another shell, open dolphin (i'm
>> under kde4-svn) and everything is faster.
>>
>> I have XFS filesystem on my home and reiserfs on root.
>>
>> Since I configured my kernel manually, maybe it could be usefull for someone
>> to
>> have my .config so I'll post it.
>>
>>
>
>
> I have just unmasked, and tried 2.6.28 on Gentoo Linux as well, and the
> problem
> appears to be gone. This is on my D820, which is the one with really bad
> throughput as well. As I am in the process of converting to 64bit on my
> D820,
> I am unable to try GUI stuff out. But, before, during heavy load, I was
> unable
> to switch between terminals very well either. Now, the system is EXTREMELY
> responsive, during these heavy load times, which is what I expect. And, I'm
> getting 82M/sec once the caching limit has been reached, and 256M/sec with
> caching. This is equivalent to what I was getting with 2.6.17.
>
> Now, I don't know if the gentoo guys applied someone's patch from here, as
> comment #52 mentioned patching 2.6.28, but it's working for me now. I'm VERY
> happy about that. :D Based on his description, it very much sounds like the
> Gentoo guys must have applied the patch. I was doing a while loop, with dd,
> increasing the amount of data by 1M at a time. The first few, up to about
> 60M,
> were getting 256M/sec. Then, I noticed in my other terminal, running vmstat,
> the iowait times got pinned to nearly 100%. So, I'm thinking that all those
> dd's that got cached, were finally catching up to the NO LIMIT on cached
> items,
> and causing thrashing in the IO system. That caused a COMPLETE freezeup of
> the
> while loop. Also, during this time, my HD light was going crazy. Then, when
> the io wait times dropped to 0 again (cached items flushed), the loop did a
> few
> more iterations (and my HD light was off), and it started all over again.
> Then, again the loop froze, etc, etc, etc.
>
>
>
Ok, so if that version is working for you of Gentoo, can we compare that
with the vanilla kernel?

Can you send us some system info to compare your kernel config with the
vanilla one?

Can we have a tarball with the following structure? (to make it easy to
diff over it)
--------------------------------------------------
systeminfo.txt
vanilla
    \- config (original config of the vanilla kernel, not yours)
    |- kernel-info.txt
    |- dmesg.txt
    |- lsmod-output.txt
    |- test-report.txt
gentoo-youredition
    \- config (the config file of your kernel version)
    |- dmesg.txt
    |- lsmod-output.txt
    |- test-report.txt
    |- gentoo.patch
--------------------------------------------------

If you have the time can you do the following on the system:
 - Get the source for that gentoo version you are using (shouldn't be to
hard on Gentoo ;-) )
 - Get the source of the vanilla kernel with the same version/patch
level as your gentoo kernel
 - Check to see if your current gentoo config is working on vanilla
kernel and if that will result in a responding system
 - If that does not solve the bug on your system, create a patch file
for the gentoo patches, so we can see exactly what gentoo has patched

If you try this and send us the information, we can use a tool like Meld
(http://meld.sourceforge.net/) to compare the 2 kernel configurations
with each other.

Can you put the following information in systeminfo.txt
    cat /proc/cpuinfo
    cat /proc/meminfo
    cat /proc/swaps

And for per kernel information:

In kernel-info.txt:
    cat /proc/version
    uname -a
    cat /proc/cmdline
    cat /sys/block/<disk>/queue/scheduler

Config is just the .config file
    You can get the info by the command zcat /proc/config.gz or via your
/boot/config-<something> or via kernel source

In dmesg.txt your dmesg output

In lsmod-output.txt your lsmod output.

In test-report the reporting of your tests on the kernel. And how they
performend and what tests you did.

In gentoo.patch the patches Gentoo made on the vanilla kernel (using the
diff command).

I hope we can find a piece of the cause with this information.

Greetings,

Michiel