Re: 2.6.10-rc3: kswapd eats CPU on start of memory-eating task

From: Voluspa
Date: Sun Dec 19 2004 - 17:42:15 EST



Found the first kernel version with the regression. It's linux-2.6.9-rc1

Perusing lkml from august there was a short thread about the oopses and loss
of keyboard in X. Applying that information in a crude hack I was able to
test the effected 2.6.9-rc1 and three -bk forward:

http://marc.theaimsgroup.com/?t=109357291300002&r=1&w=2

diff -Naur linux-2.6.9-rc1/net/sunrpc/svcauth_unix.c linux-2.6.9-rc1-debug/net/sunrpc/svcauth_unix.c
--- linux-2.6.9-rc1/net/sunrpc/svcauth_unix.c 2004-12-15 18:39:28.000000000
+0100
+++ linux-2.6.9-rc1-debug/net/sunrpc/svcauth_unix.c 2004-12-19 19:01:
53.000000000 +0100
@@ -104,7 +104,6 @@
if (test_bit(CACHE_VALID, &item->flags) &&
!test_bit(CACHE_NEGATIVE, &item->flags))
auth_domain_put(&im->m_client->h);
- kfree(im->m_class);
kfree(im);
}
}

I've since tested and retested for several hours on the different kernels. At one
point I thought the usage of lapic=lapic made a difference, but it turned
out to be a red herring.

2.6.8.1-bk2 is without doubt the last kernel to handle my testcase "properly". There
are no freezes whatsoever and the swapping is finished within 1 minute and
some seconds.

2.6.9-rc1 and forward all have the freezes. Swapping and readback takes from
3 to 6 minutes. I can't find a pattern in the time differences.

What's left now is to find some repository which has the gargantuan 2.6.9-rc1
broken out in its pieces (and I guess 2.6.8.1-bk1 and 2 must be subtracted
from that). Then reverting patches. A process where I'd need some handholding
as to what would be likely candidates.

An innocent one is Ingo's "context-switching overhead in X, ioport()" patch.
I added it to 2.6.8.1-bk2 and it didn't break my testcase.

Ah, well. It's that time of the year, so I won't be able to do any testing until
the madness is over.

Mvh
Mats Johannesson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/