From owner-freebsd-arch Wed Feb 27 11:40:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id D71EB37B400 for ; Wed, 27 Feb 2002 11:40:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020227194016.RNDL2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 27 Feb 2002 19:40:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA01420; Wed, 27 Feb 2002 11:34:49 -0800 (PST) Date: Wed, 27 Feb 2002 11:34:48 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: Slab allocator In-Reply-To: <200202271926.g1RJQCm29905@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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