From owner-freebsd-arch Thu Feb 28 11:34:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by hub.freebsd.org (Postfix) with ESMTP id 4AF6C37B405 for ; Thu, 28 Feb 2002 11:34:46 -0800 (PST) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g1SJYiD05037; Thu, 28 Feb 2002 14:34:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 28 Feb 2002 14:34:44 -0500 (EST) From: Jeff Roberson To: Terry Lambert , Cc: arch@FreeBSD.ORG Subject: Re: Slab allocator In-Reply-To: <3C7D44AE.820215AB@mindspring.com> Message-ID: <20020228142424.R529-100000@mail.chesapeake.net> 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 I'm very interested in potential optimizations to my current locking strategies. I understand why critical sections would be a good thing in the fast path. I actually started to implement it this way originally. I haven't been able to come up with a really clean way to implement the cache flushing that doesn't have some nasty side effect though. For instance, telling each cpu to flush it's caches would be somewhat possible, but then you'd need some way to effectively block and restart each cpu once the entire flush operation was done. This could lead to the page daemon thread being suspended until each cpu had entered malloc. That could be well over a time slice given that a processor may want to continue scheduling user threads and not actually do any allocations. As it is cpus are only blocked for the duration of the zone draining, so this would increase the latency here. Anyway, I'd appreciate more comments on the subject. Keep in mind the bucket flushing operations, and potentially statistics gathering as well. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message