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 Message-ID: <Pine.BSF.4.21.0202271135290.97278-100000@InterJet.elischer.org> In-Reply-To: <20020227143330.A34054@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202271135290.97278-100000>