Date: Wed, 5 Mar 2003 10:07:35 +0200 From: "Petri Helenius" <pete@he.iki.fi> To: "Bosko Milekic" <bmilekic@unixdaemons.com> Cc: <freebsd-current@FreeBSD.ORG> Subject: Re: mbuf cache Message-ID: <001201c2e2ee$54eedfb0$932a40c1@PHE> References: <0ded01c2e295$cbef0940$932a40c1@PHE> <20030304164449.A10136@unixdaemons.com> <0e1b01c2e29c$d1fefdc0$932a40c1@PHE> <20030304173809.A10373@unixdaemons.com> <0e2b01c2e2a3$96fd3b40$932a40c1@PHE> <20030304182133.A10561@unixdaemons.com> <0e3701c2e2a7$aaa2b180$932a40c1@PHE> <20030304190851.A10853@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Yeah, it kinda sucks but I'm not sure how it works... when are the
> mbufs freed? If they're all freed in a continous for loop that kinda
> sucks.
I think there is nothing really special about the driver there? The mbufs
are allocated in the driver and then freed when other parts in the kernel
are done with the packet? The issue Iīm having is that mb_free takes
almost four times the cycles than mb_alloc for each call which does
not seem to be right? I shouldnīt be having lock contention in mb_alloc
because the whole thing is still under Giant, right?
>
> > Nothing seems to be moving to the GEN pool.
>
> Lower the high watermark to like 512... wait for the next free... if
> it's still not moving, but you see that the per-cpu caches are being
> used ("in use" is changing), please let me know ASAP.
Itīs moving, however no change in performance. In use hovers
around 7000 for mbufs and clusters alike. Now the only difference
is that "in pool" also changes constantly because mbufs are shuffled
between pools.
>
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001201c2e2ee$54eedfb0$932a40c1>