Date: Wed, 28 Jun 2000 13:44:24 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Polstra G <jdp@polstra.com> Cc: current@FreeBSD.ORG Subject: Re: Questions about kmem_malloc and SPL levels Message-ID: <Pine.BSF.4.21.0006281219270.7105-100000@besplex.bde.org> In-Reply-To: <XFMail.000627103756.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Jun 2000, John Polstra G wrote: > 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(). This comment hasn't changed significantly since Net/2 or earlier. It was already wrong there. In Net/2, and still in 4.4BSDLite[1-2], both malloc() and m_clalloc() call kmem_malloc() at splimp(). The safety of this depends on malloc() not being called from non-network interrupt handlers. splhigh() would have to be used instead of splimp() if any interrupt handler could call malloc(). malloc() can be called safely from timeout interrupt handlers too, because splimp() masks timeouts. In FreeBSD, malloc() can also be called from bio interrupt handlers. splvm() = splimp() + splbio() is used for malloc() but not for m_clalloc() or m_mballoc(). > 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? malloc() calls it on kmem_map while m_clalloc() call it on mb_map, so I think there is no problem in principle. vm just has to call splvm() itself and not depend on kmem_malloc() being called at splvm() (so the comment is broken in yet another way). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006281219270.7105-100000>