Date: Mon, 9 Sep 2002 03:31:12 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Julian Elischer <julian@elischer.org> Cc: Jon Mini <mini@freebsd.org>, <arch@freebsd.org> Subject: Re: UMA locks Message-ID: <20020909032849.W47384-100000@mail.chesapeake.net> In-Reply-To: <Pine.BSF.4.21.0209081913560.51214-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Sep 2002, Julian Elischer wrote: > > > On Sun, 8 Sep 2002, Jon Mini wrote: > > > Julian Elischer [julian@elischer.org] wrote : > > > > > The UMA code is so central to all sorts of other modules that > > > if you briefly need a lock to manipulate it's per-cpu structures, > > > it is possible a spinlock might be a better choice. > > > (depending on how long you hold it for.) > > > > Being able to uma_free while holding a spinlock would be very nice. > > of course we could always drop schedlock in thread_exit(), > or do what we do do, which is call thread_stash() instead of thread_free() > when we want to free the spare thread td_spare, but then we are doing > EXTRA locking ops... hmm > > schedlock is being helppd for some quite long periods. > It's probably worth looking at it some time.. > > I believe it is safe to turn uma per cpu locks into spin locks now. Go ahead and try and do some perf runs with it. The changes should be completely localized in uma_int.h. Look for the locking macros at the bottom. 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?20020909032849.W47384-100000>