Date: Thu, 28 Feb 2002 14:34:44 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Terry Lambert <tlambert2@mindspring.com>, <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: Slab allocator Message-ID: <20020228142424.R529-100000@mail.chesapeake.net> In-Reply-To: <3C7D44AE.820215AB@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020228142424.R529-100000>