Re: anticipatory scheduler merged

[Nick Piggin <piggin@cyberone.com.au>]

Brandon Low wrote:

>On Sat, 07/05/03 at 13:33:34 -0700, Andrew Morton wrote:
>
>>- These changes have been well tested, but it is five months work and
>>  over 100 patches.  There's probably a bug or two.  If you suspect that
>>  something has gone wrong at the block layer (lots of tasks stuck in D
>>  state) then please retest with `elevator=deadline'.
>>
>>Thanks.
>>
>
>I am seeing these D tasks when running 2.5.74-mm2 under a heavy seeking
>load (compiling application, untarring kernel, and filesharing
>simultaneously) on a slow (laptop 4200RPM) hdd.  I find that after about
>10 uptime when I start throwing on the seeking loads one or all of them
>go to D state and any new disk IO is either blocked or very slow.
>
>I have tested with elevator=deadline and have been unable to reproduce.
>
>Any further testing or debugging you need me to do I can probably do
>(but I'm not terribly knowledgable so I'll need step by step for said
>testing).  Thanks!
>
>

OK, so the disk is IDE, and you aren't using ide-scsi? Please compile the
kernel with "Magic SysRq key" config option enabled. Its in the Kernel
hacking submenu.

Then repeat the system freeze, and press alt+sys rq+t. Run dmesg | less to
get the task trace. You'll get a lot of lines like this:
bash          S 00000001   627    625                 626 (NOTLB)
followed by their call traces. Copy the call trace of one or two tasks that
have a D following their name. Then post it here.

Oh and you'll probably have to run dmesg and less to get them into cache
before the system freezes!

Thanks,
Nick