From owner-freebsd-arch Tue Feb 18 20:58: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7767A37B405 for ; Tue, 18 Feb 2003 20:58:00 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95DD43F75 for ; Tue, 18 Feb 2003 20:57:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h1J4vx8h000971; Tue, 18 Feb 2003 20:57:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h1J4vxes000970; Tue, 18 Feb 2003 20:57:59 -0800 (PST) Date: Tue, 18 Feb 2003 20:57:59 -0800 (PST) From: Matthew Dillon Message-Id: <200302190457.h1J4vxes000970@apollo.backplane.com> To: Bosko Milekic Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mb_alloc cache balancer / garbage collector References: <200302171742.h1HHgSOq097182@apollo.backplane.com> <20030217154127.A66206@unixdaemons.com> <200302180000.h1I00bvl000432@apollo.backplane.com> <20030217192418.A67144@unixdaemons.com> <20030217192952.A67225@unixdaemons.com> <200302180101.h1I11AWr001132@apollo.backplane.com> <20030217203306.A67720@unixdaemons.com> <200302180458.h1I4wQiA048763@apollo.backplane.com> <20030218093946.A69621@unixdaemons.com> <200302181757.h1IHvjaC051829@apollo.backplane.com> <20030218134836.A70583@unixdaemons.com> 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 :> :> void **uma_lock = NULL; :> :> /* :> * use of *uma_lock is entirely under the control of UMA. It :> * can release block and reobtain, release and obtain another :> * lock, or not use it at all (leave it NULL). The only :> * requirement is that you call uma_cache_unlock(&uma_lock) :> * after you are through and that you not block in between UMA :> * operations. :> */ :> uma_cache_free(&uma_lock, ...) ... etc :> uma_cache_alloc(&uma_lock, ...) ... etc :> :> uma_cache_unlock(&uma_lock); :> : It's not quite that simple. You would also have to teach it how to : drop the lock if one of the allocations fails (or if it has to go to : another cache) and how to tell the caller that it has done that. :... :Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org I think you missed the double pointer. It's void **uma_lock, not void *uma_lock. i.e. UMA can use *uma_lock for whatever it wants, including dropping and reobtaining, or just dropping, or whatever. Then you could call the uma allocator a whole bunch of times with virtually no overhead. Another alternative is to simply add a mutex pointer to the current thread and allow *any* major kernel API to use it to cache an obtained mutex in order to streamline multiple calls. It would be a very powerful efficiency mechanism but would also require a mindset change on the part of kernel developers. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message