From owner-freebsd-arch Tue May 16 14:28:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 86BB037B88F for ; Tue, 16 May 2000 14:28:52 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 12rotV-000Fl6-0U; Tue, 16 May 2000 22:28:49 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id WAA05533; Tue, 16 May 2000 22:33:33 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 16 May 2000 22:33:09 +0100 (BST) From: Doug Rabson To: Nick Hibma Cc: FreeBSD Arch Mailing List Subject: Re: kobj In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 14 May 2000, Nick Hibma wrote: > > I've had a bit of a browse through the kobj source code to see what > you'd done to the newbus stuff in order to separate the two. > > One of my main issues with it is that kobj_compile_methods panics in low > memory situations. It should return an error code / NULL. It's not > necessarily fatal if an object can't be created. I consider kobj very > similar to malloc, except that it embeds a bit of functionality in the > allocated struct. I can change it to return NULL I think. Actually, I should pass a set of malloc flags to kobj_class_compile() so that the caller can decide whether to sleep for memory. I also have some pending changes which allow the caller to pre-allocate memory for the ops cache allowing kobj to be used before malloc(9) is available. > > Second, two minor nits (or signs of brain damage on my side). You call > kobj_init twice in subr_bus.c:make_device. > And you call kobj_class_compile in subr_bus.c:root_bus_module_handler > explicitly and through kobj_init, implicitly. The second call is redundant - I have removed it. > > One last thing: KOBJ_CACHE_SIZE is by default set to 256. I find that > rather large (1kb) considering the number of methods in use currently in > newbus (per file, possibly multiple MODULES): > > 15 ./dev/iicbus/iicsmb.c > 16 ./i386/i386/nexus.c > 18 ./dev/eisa/eisaconf.c > 19 ./dev/mca/mca_bus.c > 20 ./pccard/pccard_nbk.c > 21 ./dev/pccard/pccard.c > 22 ./dev/ata/ata-all.c > 23 ./pci/pci.c > 27 ./isa/isa_common.c > 29 ./pci/pcisupport.c > > I suggest something like 120 or less (less than a power of two to make > the object fit in an allocation of a power of 2. This is a cost per-class, not per-object so perhaps a 1kb cost per-class is not too unreasonable. The size of the ops cache must be a power of two otherwise the method dispatch involves a divide which would slow it down by a factor of about 5. I found when testing that (at least on ia32), 256 was a good choice since the compiler managed to optimise the dispatch code much better. Possibly a cache size of 64 or 32 would be appropriate but this would probably slow down method dispatch by about 10-20%. > > Hope these comments are of any use. Very useful, thanks. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message