* John Polstra G <[EMAIL PROTECTED]> [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.

"I have the heart of a child; I keep it in a jar on my desk."

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to