From owner-freebsd-current Tue Jun 27 10:38: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 825ED37BE71 for ; Tue, 27 Jun 2000 10:38:03 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id KAA13299 for ; Tue, 27 Jun 2000 10:37:56 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 27 Jun 2000 10:37:56 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra G To: current@freebsd.org Subject: Questions about kmem_malloc and SPL levels Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The comment leading into kmem_malloc (in sys/vm/vm_kern.c) is worrying me: * This routine has its own private kernel submap (kmem_map) and object * (kmem_object). This, combined with the fact that only malloc uses * this routine, ensures that we will never block in map or object waits. Actually, this function is called by m_clalloc (in sys/kern/uipc_mbuf.c) too. The comment is obviously wrong. Is it a problem that this assumption is violated? * Note that this still only works in a uni-processor environment and * when called at splhigh(). The first part will be news to the folks running SMP. :-) The business about splhigh is also wrong. But what worries me is that malloc calls it at splmem, while m_clalloc calls it at splimp. Is that a problem? John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message