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. Best regards, Ricardo
