Date: Tue, 27 Jun 2000 10:46:06 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: John Polstra G <jdp@polstra.com> Cc: current@FreeBSD.ORG Subject: Re: Questions about kmem_malloc and SPL levels Message-ID: <20000627104606.L275@fw.wintelcom.net> In-Reply-To: <XFMail.000627103756.jdp@polstra.com>; from jdp@polstra.com on Tue, Jun 27, 2000 at 10:37:56AM -0700 References: <XFMail.000627103756.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* John Polstra G <jdp@polstra.com> [000627 10:38] 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(). > > 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? The comment is wrong, the idea is that only network interupts are expected to play with the mbmap, therefore we only need to block network interrupts during mbuf allocation. The general malloc pool can be accessed from any interrupt and therefore needs protection at splhigh. If there were 'diskbufs' and they had thier own private map then you'd only really need splbio wrapped around the call. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20000627104606.L275>