Date: Tue, 16 May 2000 22:33:09 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Nick Hibma <n_hibma@calcaphon.com> Cc: FreeBSD Arch Mailing List <arch@freebsd.org> Subject: Re: kobj Message-ID: <Pine.BSF.4.21.0005162224370.47945-100000@salmon.nlsystems.com> In-Reply-To: <Pine.BSF.4.20.0005122217010.73091-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005162224370.47945-100000>