Messages in this thread |  | | Date | Tue, 3 Oct 2000 02:35:53 +0200 (CEST) | From | Martin Diehl <> | Subject | Re: 2.4.0-test9-pre8 |
| |
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/
|  |