Date: Thu, 08 May 2008 11:10:15 -0400 From: gnn@freebsd.org To: Giorgos Keramidas <keramida@freebsd.org> Cc: arch@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: Accounting for mbufs and clusters assigned to a socket buffer Message-ID: <m2skwszvag.wl%gnn@neville-neil.com> In-Reply-To: <8763tqkdk3.fsf@kobe.laptop> References: <m2bq3y6yk3.wl%gnn@neville-neil.com> <4811E384.5020604@freebsd.org> <m27ieiq1sz.wl%gnn@neville-neil.com> <8763tqkdk3.fsf@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
At Wed, 07 May 2008 06:17:48 +0300, Giorgos Keramidas wrote: > > I guess we could check *both* (m_flags & M_EXT) and m_ext.ext_type. > > This won't really show how many mbufs use a classic cluster vs. a 9k > cluster, but checking for all the m_ext.ext_types is probably going to > look a bit ugly in a single if-check :( > > We have at least EXT_CLUSTER, EXT_JUMBOP, EXT_JUMBO9, EXT_JUMBO16 and > EXT_PACKET which may be interesting for cluster-related accounting, but > in socketvar.h we can't really use the uma zone accounting. I just > noticed that the 'interesting' ext_types are conveniently short integers > though. Maybe we could change sb_ccnt to a small array, and then change > > if ((m)->m_flags & M_EXT) \ > (sb)->sb_ccnt += 1; > > to something like: > > if ((m)->m_flags & M_EXT && (m)->m_ext.ext_type < EXT_MBUF) \ > (sb)->sb_ccnt[(m)->m_ext.ext_type - 1] += 1; \ > > With our current ext_type's > > #define EXT_CLUSTER 1 /* mbuf cluster */ > #define EXT_SFBUF 2 /* sendfile(2)'s sf_bufs */ > #define EXT_JUMBOP 3 /* jumbo cluster 4096 bytes */ > #define EXT_JUMBO9 4 /* jumbo cluster 9216 bytes */ > #define EXT_JUMBO16 5 /* jumbo cluster 16184 bytes */ > #define EXT_PACKET 6 /* mbuf+cluster from packet zone */ > #define EXT_MBUF 7 /* external mbuf reference (M_IOVEC) */ > ... > > the [ext_type - 1] would move the burden of parsing the ext_type at the > place where we actually have to print something about the sb_ccnt > counters. > > Would the 'bloat' of u_int[6] for ext_type's which are unused be too > much to keep around? I don't know if we want to go that far, but we could certainly try it. I'll keep it in mind. Thanks, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2skwszvag.wl%gnn>