From owner-freebsd-current Wed Jan 20 16:12:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07434 for freebsd-current-outgoing; Wed, 20 Jan 1999 16:12:29 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07419 for ; Wed, 20 Jan 1999 16:12:25 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id LAA15843; Thu, 21 Jan 1999 11:12:16 +1100 Date: Thu, 21 Jan 1999 11:12:16 +1100 From: Bruce Evans Message-Id: <199901210012.LAA15843@godzilla.zeta.org.au> To: bde@zeta.org.au, mike@smith.net.au Subject: Re: Truth to M_WAITOK? Cc: current@FreeBSD.ORG, green@unixhelp.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Bear with the ignorance a moment; how is a full map any different to no >more kmem space? I'd call them the same. The map is kmem_map for malloc(), and running out of space in that map is fatal. When the map fills up, it is usually not really full, it is just so fragmented that contiguous space can't be found for the larger than usual allocation in the current request. Freeing memory in the map won't necessarily reduce fragmentation. The map must be quite sparse to work at all. >In the "out of kmem" case, we call VM_WAIT and retry. Why not do this >in the kmem_map full case as well? I'd call that the the out of general memory (pages) case. This is non- fatal because normally lots of memory is allocated to applications and it is easy to free some by swapping. There are no fragmentation problems since pages can be mapped anywhere in virtual memory. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message