Subject: Re: kernel stack overflow detection
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 05/30/2002 15:12:47
> in the absence of a swap device, how does one prevent
> resource(memory) starvation and hence a deadlock under UVM?
As far as I can tell, the answer is "don't allocate too much memory".
As a few tech-kerners may recall, I've worked with swapless systems a
little and have run into deadlocks that look like this - contact me
off-list and we can talk about it in more detail, if you want. I was
mostly told "fixed in -current"; I've done some tests under -current
and haven't had it deadlock yet, though I also haven't stressed it as
much as the older kernel that did deadlock.
> is it possible that a ramdisk will aggrevate a deadlock?
I can't see why, unless it's an mfs-style ramdisk that wasn't set to
allocate real RAM at startup, in which case writing stuff to it could
(try to) allocate real RAM and thereby exacerbate a RAM shortage. (One
of the patches in my patch tree adds an option to mount_mfs which makes
it mlock() the memory, which also makes it allocate real pages. If you
have no swap, all anonymous memory is de-facto locked in core anyway,
so the locking aspect of mlock is irrelevant. The patches are in
ftp.netbsd.org:/pub/NetBSD/misc/mouse/patch-tree/src/sbin/newfs/ if
you're interested.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B