Hi, On Sep,Saturday 5 2009, at 3:33 PM, Pawel Jakub Dawidek wrote: > On Sat, Sep 05, 2009 at 03:22:12PM +0200, Ricardo M. Correia wrote: >> On Sat, 2009-09-05 at 15:08 +0200, Pawel Jakub Dawidek wrote: >>>> Unfortunately your fix will not work correctly, because the DMU >>>> code >>>> expects all of the dnode_t fields to be initialized to 0 after >>>> allocation, which will not happen if you eliminate that call. >>> >>> And this is not what constructor is doing? Could you explain what >>> doesn't work here exactly? From my understanding (at least that's >>> the >>> case for FreeBSD's zone allocator) kmem_cache will call constructor >>> after allocating the memory. If it isn't called after allocation >>> then >>> when? >> >> Well, in Linux and Solaris, the constructor is called only when an >> entire slab is allocated internally by the kmem code, not when the >> one >> of the objects in the slab is allocated (by calling kmem_cache_alloc >> ()). >> >> In fact, the only thing kmem_cache_alloc() usually does is to just >> retrieve a pointer from a per-CPU array of pointers and decrement a >> counter (except if there are no more pointers available, in which >> case >> the cache is refilled). >> >> But if in FreeBSD kmem_cache_alloc() calls the constructor, then I >> guess >> you can live with your simple fix instead, no need for the >> complicated >> fix. > > I see, thanks for explanation. Yes, FreeBSD always calls the > constructor, > even if the memory is taken from cache.
Thanks for finding this, this is problem for NetBSD too then. Regards Adam.
