On 02.12.02 00:21 Andrea Arcangeli wrote:
>
> ok, now it's clear what the problem is. there are inuse-dirty inodes
> that triggers a deadlock in the schedule-capable
> try_to_sync_unused_inodes of 2.4.20rc2aa1 (that avoided me to backout an
> otherwise corrupt lowlatency fix). It can trigger only in UP,
> in SMP the other cpu can always run kupdate that will flush all dirty
> inodes, so it would lockup one cpu as worse for 2.5 sec, this is
> probably why I couldn't reproduce it, I assume all of you reproducing
> the deadlock were running on an UP machine (doesn't matter if the kernel
> was compiled for SMP or not).
>
> Can you give a spin to this untested incremental fix?
[snip snip]
Yes, this does the trick for me. With this fix it survived the last 30m
of torture (consisting of make -j4 bzImage, a gcc build plus 2 mozillas
and 1 OpenOffice.org word processor, bear in mind it is only a P200 box)
blissfully -- previously it took only 15 seconds with a 1/3 that load to
lock up. So, this patch definitely cures it.
Nuno
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:11 EST