From owner-freebsd-current Fri May 2 05:20:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA27880 for current-outgoing; Fri, 2 May 1997 05:20:30 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA27873 for ; Fri, 2 May 1997 05:20:26 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id IAA27851; Fri, 2 May 1997 08:19:20 -0400 (EDT) From: Peter Dufault Message-Id: <199705021219.IAA27851@hda.hda.com> Subject: Re: vnode->v_usage In-Reply-To: <220.862574439@critter> from Poul-Henning Kamp at "May 2, 97 02:00:39 pm" To: phk@dk.tfs.com (Poul-Henning Kamp) Date: Fri, 2 May 1997 08:19:20 -0400 (EDT) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Moving items between two lists should be atomic - it is common > >and lends itself to clean implementation. > It's actually the same list in this case... > > >Aside: how about making the queues truly opaque while you're doing this? > >Then you have a single place to enable locking hierarchy violation detection, > >*CAS types of implementations, etc. > > I don't think that would be very easy. On the other hand, there > are very few pieces of code manipulating the vnode free list, do > it's hardly worth the effort. Or did I misunderstand you ? I meant this: if I had the time for some research I'd replace all the *Q* macros with a single opaque data structure (and most likely a single flavor of queue) with access functions and see what effect that had on system performance. I'd push operations that leant themselves to non-locking approaches (e.g., moving between lists) down there and try to use those. I doubt the performance hit would be much. Then the locking could be kept down there. Let this slide - it is idle speculation. > if (simple_lock_try(&vnode_free_list_slock)) { I have to look at vtouch now since I don't know that you aren't committed to do the move to the tail. Can't someone have locked the freelist for another reason? If you don't have to do the move it looks good. There is still an ordering, as you know, and I'll have to find the "white paper" that explains how the lock ordering is supposed to work. Anyway, it looks fun. It is good to see this showing up in FBSD. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936