Hi,
On Mon, 2 Oct 2000, Rik van Riel wrote:
> On Sun, 1 Oct 2000, Linus Torvalds wrote:
>
> > - pre8:
> > - quintela: fix the synchronous wait on kmem_cache_shrink().
> > This should fix the mmap02 lockup.
>
> It probably doesn't. People will want to apply my patch
> (on http://www.surriel.com/patches/) to -test9-pre8 to
> see if that really makes the box solid.
just repeated the tests wich caused deadlocks on my UP-box (192M RAM,
500M swap) using 2.4.0-t9p8 + 2.4.0-t9p7-vmpatch. All tests done in
single-user (why? - see below):
- mmap002: no deadlock anymore
- swptst (provided by Mark Galbraith - basically ipc001 with shmget()
+friends replaced by anonymous mmap()): no deadlocks anymore
- boot with mem=8M und doing (several simultaneous) dd's if=/dev/urandom
of=/dev/null with bs=10M: fine too
- boot with mem=8M and make bzImage: works too
so far for the good news - however, there is some bad too as I still
have 3 "box lockup" situations. The first one (not covered here) is at
IDE-initialization when booting and needs more investigantion.
The other 2 are VM-related:
* deadlock in initscripts (even for runlevel 2). SysRq shows idle_task
being the only one ever getting the CPU when deadlocked. I think I'll
have to hack my initscripts to analyze this step by step to provide
more information, if I'm the only one, hanging there.
* Following a suggestion from Jeff Garzik to save the disk from heavy
trashing during my mem=8M test, I've tried to use a ramdisk for
swapping - Yes, I know, this is pretty stupid in normal use and might
even be illegal (i.e. not expected to work by design). Anyway, I've
tried it and was working when used as a swapdevice (size=64M, bs=4k).
Added with priority 0 and the normal swap partition kept for fallback
with prio=-1. No problems. It did even gracefully swapoff the ramdisk
while it was already filled and the box was swapping to disk.
To make thinks even more stupid, I've tried a second thing: create
an ext2-fs (bs=4k) on the ramdisk, mount it, and use a swapfile on
top of it. This deadlocks (with kswapd being current forever) at the
very moment the swapfile ist filled and swapping has to go to the
fallback raw swap partition.
As already said, I wouldn't be surprised, if swapping to rd were
broken. But swapping to a rd-partition appears solid while a rd-based
swapfile deadlocks. Could the difference be explained somehow or might
it indicate some deadlock path due to VM-fs interaction not
covered otherwise - so far?
More comments:
2.4.0-t9p8 + 2.4.0-t9p7-vmpatch appears to be a big step in the
right direction. What did impress me most, was the performance boost:
make bzImage with mem=8M needed about 2h to complete - whereas for
t9p7 it was 6-7h! According to vmstat the difference goes in parallel
with CPU-utilisation (u/s/i=10/30/60 for t9p8, was something like 2/8/90
for t9p7).
Haven't tried other combinations (vanilla t9p8 or t9p7+t9p7-vmpatch f.e.)
Waiting for Rik's next patch recently announced to look for the initscript
issue - if it's still there then.
Regards
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:11 EST