Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2002 11:34:48 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG
Subject:   Re: Slab allocator
Message-ID:  <Pine.BSF.4.21.0202271128580.97278-100000@InterJet.elischer.org>
In-Reply-To: <200202271926.g1RJQCm29905@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Wed, 27 Feb 2002, Matthew Dillon wrote:

> 
> :PS Sorry for the long winded email. :-)
> 
>     Well, one thing I've noticed right off the bat is that the code
>     is trying to take advantage of per-cpu queues but is still
>     having to obtain a per-cpu mutex to lock the per-cpu queue.

I was wondering abuot that myself :-)


> 
>     Another thing I noticed is that the code appears to assume
>     that PCPU_GET(cpuid) is stable in certain places, and I don't
>     think that condition necessarily holds unless you explicitly
>     enter a critical section (critical_enter() and critical_exit()).
>     There are some cases where you obtain the per-cpu cache and lock 
>     it, which would be safe even if the cpu changed out from under 
>     you, and other case such as in uma_zalloc_internal() where you 
>     assume that the cpuid is stable when it isn't.

It is definitly not ok to assume that PCPU_GET(anything except curthread)
is stable unless you have pre-emtion disabled. (e.g. via the crit_mumble()
functions or straight interrupt dissablement. WHen jhb adds the
pre-emption code, it is quite possible that you may be pre-empted at any
unprotected point, and may be restarted on a different processor.
curthread is an obvious exception as it travels with you..


> 
> 	* Documentation.  i.e. comment the code more, especially
> 	  areas where you have to special-case things like for
> 	  example when you unlock a cpu cache in order to
> 	  call uma_zfree_internal().

yes, LOTS more comments please. Particularly giving the REASON
you do things.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" 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.0202271128580.97278-100000>