From owner-freebsd-arch  Wed Feb 27 12: 0:28 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 9AE6F37B400
	for <arch@FreeBSD.ORG>; Wed, 27 Feb 2002 12:00:23 -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 <20020227200023.SBRW2951.rwcrmhc53.attbi.com@InterJet.elischer.org>;
          Wed, 27 Feb 2002 20:00:23 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA01466;
	Wed, 27 Feb 2002 11:41:51 -0800 (PST)
Date: Wed, 27 Feb 2002 11:41:50 -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: <20020227143330.A34054@unixdaemons.com>
Message-ID: <Pine.BSF.4.21.0202271135290.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 09:58:09AM -0800, Terry Lambert wrote:
> > First, let me say OUTSTANDING WORK!
> > 
> > Jeff Roberson wrote:
> > > There are also per cpu queues of items, with a per cpu lock.  This allows
> > > for very effecient allocation, and also it provides near linear
> > > performance as the number of cpus increase.  I do still depend on giant to
> > > talk to the back end page supplier (kmem_alloc, etc.).  Once the VM is
> > > locked the allocator will not require giant at all.
> > 
> > What is the per-CPU lock required for?  I think it can be
> > gotten rid of, or at least taken out of the critical path,
> > with more information.
> 
>   Per-CPU caches. Reduces lock contention and trashes caches less often.

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)


>  


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