Date: Wed, 5 Mar 2003 01:12:55 +0200 From: "Petri Helenius" <pete@he.iki.fi> To: "Bosko Milekic" <bmilekic@unixdaemons.com> Cc: <freebsd-current@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG> Subject: Re: mbuf cache Message-ID: <0e2b01c2e2a3$96fd3b40$932a40c1@PHE> References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <20030304173809.A10373@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Any comments on the high cpu consumption of mb_free? Or any other places
> > where I should look to improve performance?
>
> What do you mean "high cpu consumption?" The common case of mb_free()
> is this:
According to profiling mb_free takes 18.9% of all time consumed in kernel and is
almost double to next cpu consuming function. Since I´m looking how to optimize
the system, it´s usually a good idea to start looking where most CPU is spent.
For example, I´m wondering if mbufs get unneccessarily freed and allocated or thrown
around different buckets because of the tunables are wrong. I´m not saying that
there must be something wrong with the code itself.
For example what does "in use" mean below: There is no way there is enough
traffic on the system to allocate 7075 mbufs when this netstat -m was taken.
mbuf usage:
GEN cache: 0/0 (in use/in pool)
CPU #0 cache: 7075/8896 (in use/in pool)
CPU #1 cache: 1119/4864 (in use/in pool)
Total: 8194/13760 (in use/in pool)
Mbuf cache high watermark: 8192
Mbuf cache low watermark: 128
Pete
>
> bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)];
> owner = bucket->mb_owner & ~MB_BUCKET_FREE;
> switch (owner) {
> ...
> default:
> cnt_lst = MB_GET_PCPU_LIST_NUM(mb_list, owner);
> MB_PUT_OBJECT(m, bucket, cnt_lst);
> MB_MBTYPES_DEC(cnt_lst, type, 1);
> if (bucket->mb_owner & MB_BUCKET_FREE) {
> SLIST_INSERT_HEAD(&(cnt_lst->mb_cont.mc_bhead),
> bucket,
> mb_blist);
> bucket->mb_owner = cnt_lst->mb_cont.mc_numowner;
> }
> }
>
> That's the common path, modulo a couple checks on whether or not the
> container being freed to needs to be moved or whether we're in a
> starvation situation. The only thing to be done, possibly, is make
> the routine smaller by moving those couple of actions to seperate
> routines, but I'm not clear that this is very useful, given that
> mb_free()'s usage is restricted to only inside subr_mbuf.c
>
> > Pete
>
> --
> Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0e2b01c2e2a3$96fd3b40$932a40c1>