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