On Thu, 2011-04-28 at 13:59 -0600, Neil Perrin wrote: > On 4/28/11 12:45 PM, Edward Ned Harvey wrote: > > > > In any event, thank you both for your input. Can anyone answer these > > authoritatively? (Neil?) I'll send you a pizza. ;-) > > > > - I wouldn't consider myself an authority on the dedup code. > The size of these structures will vary according to the release you're > running. You can always find out the size for a particular system using > ::sizeof within > mdb. For example, as super user : > > : xvm-4200m2-02 ; echo ::sizeof ddt_entry_t | mdb -k > sizeof (ddt_entry_t) = 0x178 > : xvm-4200m2-02 ; echo ::sizeof arc_buf_hdr_t | mdb -k > sizeof (arc_buf_hdr_t) = 0x100 > : xvm-4200m2-02 ; >
yup, that's how I got them. Just to add to the confusion, there are typedefs in the code which can make names slightly different: typedef struct arc_buf_hdr arc_buf_hdr_t; typedef struct ddt_entry ddt_entry_t; I got my values from a x86 box running b159, and a SPARC box running S10u9. The values were the same from both. E.g.: root@invisible:~# uname -a SunOS invisible 5.11 snv_159 i86pc i386 i86pc Solaris root@invisible:~# isainfo amd64 i386 root@invisible:~# mdb -k Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti arp usba uhci fctl stmf kssl stmf_sbd sockfs lofs random sata sd fcip cpc crypto nfs logindmux ptm ufs sppp ipc ] > ::sizeof struct arc_buf_hdr sizeof (struct arc_buf_hdr) = 0xb0 > ::sizeof struct ddt_entry sizeof (struct ddt_entry) = 0x178 > This shows yet another size. Also there are more changes planned within > the arc. Sorry, I can't talk about those changes and nor when you'll > see them. > > However, that's not the whole story. It looks like the arc_buf_hdr_t > use their own kmem cache so there should be little wastage, but the > ddt_entry_t are allocated from the generic kmem caches and so will > probably have some roundup and unused space. Caches for small buffers > are aligned to 64 bytes. See kmem_alloc_sizes[] and comment: > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/kmem.c#920 > Ugg. I hadn't even thought of memory alignment/allocation issues. > Pizza: Mushroom and anchovy - er, just kidding. > > Neil. And, let me say: Yuck! What is that, an ISO-standard pizza? Disgusting. ANSI-standard pizza, all the way! (pepperoni & mushrooms) -- Erik Trimble Java System Support Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
