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. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20090905/c88f5f63/attachment.bin>
