Date: Wed, 27 Feb 2002 12:57:15 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Julian Elischer <julian@elischer.org>, Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG Subject: Re: Slab allocator Message-ID: <3C7D482B.984F6FE7@mindspring.com> References: <20020227143330.A34054@unixdaemons.com> <Pine.BSF.4.21.0202271135290.97278-100000@InterJet.elischer.org> <20020227150519.A42681@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. This is ridiculous: 1) Kernel preemption should *never* result in CPU migration. 2) Allocations at interrupt level are an extreme special case, and should be handled as a special case, so as not to damage the performance of the common case. The degenerate scenario in interrupt allocation can always be handled by simply pre-allocating resources on a per driver instance basis, and then renewing the allocations in the upper level code. This results in a per driver instance used-but-free pool retention, but given the other wastage, it's a comparatively small penalty to pay. UnixWare used this method to allocate driver buffers, at one point in time (SVR4 ES/MP). Given the shared code, I'm pretty sure Solaris did, as well. Personally I think interrupt allocations can be handled at a much lower cost, anyway, without resorting to such tricks. Bruce Evans had a good suggestion in this regard some time back; it's probably time to dust it off. -- Terry 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?3C7D482B.984F6FE7>