[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=bqnaif=7xdLFDny86-WYJONRZB45Q=ekKMMst@mail.gmail.com>
Date: Tue, 1 Feb 2011 22:24:00 +0100
From: Jindřich Makovička <makovick@...il.com>
To: Andrea Arcangeli <aarcange@...hat.com>
Cc: linux-kernel@...r.kernel.org, Mel Gorman <mel@....ul.ie>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: khugepaged: gets stuck when writing to USB flash, 2.6.38-rc2
2011/2/1 Andrea Arcangeli <aarcange@...hat.com>:
>> When copying 4GB or more in one go from HDD to Flash, during the
>> copying, fork() and probably other syscalls involving VM start
>> blocking (I first observed the problem in Chrome, which refused to
>> display content in new tabs). When one lets the copying finish, the
>> system returns to a usable state.
>>
>> During the limbo, khugepaged is in D state (uninterruptible sleep).
>
> That means no hugepage could be allocated. Maybe memory compaction is
> doing an overwork because all pagecache is dirty and can't be
> migrated. This should solve it if it's memory compaction:
>
> echo never >/sys/kernel/mm/transparent_hugepage/defrag
>
> kswapd state would be interesting too. Can you sysrq+t?
With -rc2, there is
$ ps aux | grep -E "kswap|khugep"
root 474 0.0 0.0 0 0 ? S 20:44 0:00 [kswapd0]
root 540 0.0 0.0 0 0 ? DN 20:44 0:00 [khugepaged]
Sysrq-t output is attached.
Good news is, I don't see these issues with -rc3.
Regards,
--
Jindrich Makovicka
Download attachment "sysrq-t.txt.gz" of type "application/x-gzip" (14135 bytes)
Powered by blists - more mailing lists