[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikRn9hUb6dgGBGvF8czRxqLxm8utXR+iEN17cs1@mail.gmail.com>
Date: Thu, 7 Oct 2010 17:15:50 +0200
From: Torsten Kaiser <just.for.lkml@...glemail.com>
To: Tejun Heo <tj@...nel.org>
Cc: lkml <linux-kernel@...r.kernel.org>
Subject: Re: -mm: xfs lockdep warning
On Thu, Oct 7, 2010 at 4:05 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On 10/07/2010 03:21 PM, Torsten Kaiser wrote:
>>> Can you test whether the following patch fix the issue?
>>
>> Yes. After adding this patch to 2.6.36-rc6 it survived my testcase. It
>> first seems to get stuck again, but after less then a minute the
>> system recovered and all compiles finished successfully.
>>
>> I suspect the combination of CFLAGs, the gcc version and maybe even
>> changes in KOffice from 2.2.1 to 2.2.2 are import for my testcase. It
>> looks like at the start of the complies something is really eating an
>> enormous amount of memory and I did not hit such a case with earlier
>> kernels.
>
> It's great to hear that the patch helped but would you be able to
:-(
The second try with the patched 2.6.36-rc6 got stuck again.
> repeat the same test w/ 2.6.35 and see whether there's any noticeable
> difference?
I just tested vanilla 2.6.35, userspace and the testcase as with the
2.6.36-rc6 kernel.
Behavior was the same as with the first try of the patched 2.6.36-rc6:
The testcase started to build up CPU load and memory pressure, then
the mouse got stuck. After ~1 min the system recovered and KDE became
usable again. (Compile just finish OK)
vmstat 60 from 2.6.35:
2 0 0 2365848 1060 742072 0 0 205 7 6467 12252 26 5 62 8
17 0 0 837936 1060 1079520 0 0 1025 24 2210 13483 69 20 8 2
18 0 0 694296 1060 1127728 0 0 231 14 626 1883 74 26 0 0
20 0 0 228540 124 998440 0 0 48 12 604 1820 72 28 0 0
23 1 24 195456 52 657216 0 0 339 11 563 1669 84 16 0 0
0 42 937144 14004 0 164352 0 15617 290 15633 827 1254 24 9 1 66
21 1 861184 776104 0 149908 998 3852 2790 3902 1137 2454 45 15 0 40
21 0 798544 1131964 0 190004 212 0 530 15 599 1469 87 13 0 0
12 1 779488 1536772 0 225312 195 0 398 12 534 1087 88 12 0 0
11 0 620620 2201408 0 273976 1338 0 1638 40 851 2281 75 19 3 3
12 1 588196 1572564 0 344232 521 0 1326 152 787 1888 86 14 0 0
8 0 510876 2286000 0 311464 127 0 442 398 758 1558 88 12 0 0
> Some level of stuttering is expected if the system is hit
> with sudden huge spike of memory pressure but let's see if it has
> regressed somehow.
Yes, if a swapstorm occurs, I can live with a (short) "lockup". For
example compiling openoffice on tmpfs is a case where I have seen
similar short periods of the mouse getting stuck. But with 2.6.36-rc5
it was the first time that the system did not seem to recover, so I
think it should count as a regression compared to 2.6.35.
As the second try with the patched 2.6.36-rc6 got stuck again, could
it be that your patch is incomplete?
>From drivers/md/dm-crypt.c:
cc->io_queue = create_singlethread_workqueue("kcryptd_io");
cc->crypt_queue = create_singlethread_workqueue("kcryptd");
Do these workqueues also need WQ_MEM_RECLAIM?
I have attached the SysRq-M output from the patched -rc6. The symptoms
were the same as with the unpatched kernel. The system got stuck, the
hung_task_timeout triggered for a numer of programs in sync_page() or
do_lookup() and one kworker/1:1:496 was probable the nail in the
coffin.
Do you want me to do more tests with 2.6.35 or the patched .36-rc6? Or
any other patch I should try?
Torsten
View attachment "hang-with-patch.txt" of type "text/plain" (33978 bytes)
Powered by blists - more mailing lists