Date: Wed, 26 May 2004 15:47:41 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: bjohns123@msn.com, freebsd-hackers@freebsd.org Subject: Re: KVA space problems? Message-ID: <200405262047.i4QKlfOK028775@casselton.net> In-Reply-To: <BAY8-F8SjjUgRc9nYKS000417c2@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This has been seen before and there is at least one open problem report that the kernel malloc() unexpectantly returns NULL in WAITOK situations. http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/53382 --- I think malloc returns before your patch, namely around line 199: va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags ); if (va == NULL) { splx(s); return ((void *) NULL); } Although, I agree that the kernel malloc() should not do this, if KVM is depleted or fragmented to this point, I suspect your changes of simply retrying again will cause an infinite loop in malloc(). If malloc() sleeps waiting for KVM to be freed, my guess this will lead to the processes to hang for a long time if not forever. I think this because people are bumping the MBUFs numbers up and not changing the KVM size, once the KVM is depleted/fragmented it shouldn't come down for a long time. --- The pre 5.x VM assumes KVM will not be depleted. contigmalloc() used to leak physical pages if the KVM got depleted. I was told "the system will panic soon anyway, why put them back". --Mark Tinguely
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405262047.i4QKlfOK028775>