From owner-freebsd-arch  Wed Feb 27 12:20:26 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87])
	by hub.freebsd.org (Postfix) with ESMTP id 6EE9037B400
	for <arch@FreeBSD.ORG>; Wed, 27 Feb 2002 12:20:12 -0800 (PST)
Received: from InterJet.elischer.org ([12.232.206.8])
          by rwcrmhc54.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020227202012.YFQJ1214.rwcrmhc54.attbi.com@InterJet.elischer.org>;
          Wed, 27 Feb 2002 20:20:12 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA01633;
	Wed, 27 Feb 2002 12:17:31 -0800 (PST)
Date: Wed, 27 Feb 2002 12:17:30 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Bosko Milekic <bmilekic@unixdaemons.com>
Cc: Terry Lambert <tlambert2@mindspring.com>,
	Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG
Subject: Re: Slab allocator
In-Reply-To: <20020227150519.A42681@unixdaemons.com>
Message-ID: <Pine.BSF.4.21.0202271210460.97278-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG



On Wed, 27 Feb 2002, Bosko Milekic wrote:

> 
> On Wed, Feb 27, 2002 at 11:41:50AM -0800, Julian Elischer wrote:
> > The idea of Per CPU caches is that only that CPU is accessing it so 
> > therefore you shouldn't need a lock at all. unless you are protecting 
> > against interrupts on your own processor
> > and pre-emption. There are also ways to implement atomic
> > operations on queues that require no locks at all.
> > (e.g. using the test and swap instruction)
> 
>   Yes, that's exactly the point. You have to protect against pre-emption
> and interrupts.
maybe use a critical section instead.. 
or better, a test/swap
or, both...

but it sounds like you need the lock anyhow because
as you said.. it is possible a recently pre-empted thread may continue 
to use the pool of it's old processor for a short moment,
(I'm not sure I like that idea)

> 
> -- 
> Bosko Milekic
> bmilekic@unixdaemons.com
> bmilekic@FreeBSD.org
> 
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message