On Tue, 3 Oct 2000, Martin Diehl wrote:
> * deadlock in initscripts (even for runlevel 2). SysRq shows idle_task
> being the only one ever getting the CPU when deadlocked.
This suggests tasks yielding the CPU while task->state !=
TASK_RUNNABLE, which results in them never being rescheduled
again ...
(time to hunt down the rescheduling points)
> * 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?
Could be. I'll look into this since it could make a difference
to swap-over-nbd as well ...
> 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!
Thanks go out to Ananth for spotting the bug which caused
this ;)
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
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:12 EST