:On Fri, Dec 05, 2003 at 11:15:20AM -0500, Dwayne MacKinnon wrote:
:> Hi,
:>=20
:> I'm wondering if this could possibly be related to a problem I was=20
:> having with my 4.9-RELEASE box. Twice in two days it hung on me=20
:> completely, and started spouting the following error messages:
:
:Well, the error condition Matt is talking about only occurs if you had
:run your system completely out of kernel memory. That's not likely;
:far more likely is that you have a dodgy drive, controller or cabling.
:
:Kris
Dwayne's problem is not likely to be related unless there is another
memory related bug that I haven't found yet.
--
Actually Kris's comment isn't quite correct. You don't have to run the
system completely out of memory for malloc(M_NOWAIT) to fail. The system
simply needs to run out of free pages (if called from an interrupt), or
free+cache pages (if called from a non-interrupt). Also, non-interrupt
allocations will not eat into the free page list beyond a certain
point because a number of pages have to be reserved for interrupt based
allocations.
For example, you could have a ton of pages in the cache but not a one
of these can be touched by an interrupt, and you could have minimal or
no pages in the cache but a ton of inactive pages and M_NOWAIT will
return NULL because, obviously, it isn't going to wait for the
page daemon to recycle some pages.
So it is far easier to temporarily run the system out of memory such
that M_NOWAIT causes malloc() to return NULL then I guess most people
expect. That's why M_NOWAIT should only be used in situations where
NULL can actually be returned without fragging the system up. That is
not how it is being used in the ATA driver.
Now it is possible that the SLAB allocator works somewhat differently
in 5.x, but I think the VM page queue issues still stand even there.
-Matt
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
