Re: mbufs and cluster
Re: mbufs and cluster
- Subject: Re: mbufs and cluster
- From: Mike Smith <email@hidden>
- Date: Mon, 15 Aug 2005 15:28:30 -0700
On Aug 15, 2005, at 1:30 PM, Michael Tuexen wrote:
the principal problem I see is, that an Mac OS X system uses more
and more mbuf clusters
over the time and there is no chance to get them back. From my
understanding the state of
the system before and after running a user program should be the
same (in terms of used
kernel buffers and so on).
Your understanding is wrong. Not only in this regard; the state of
the VM/buffer cache and many
other parts of the system is mutated by such an event.
Are you really saying, that one should reboot the system after
a program was run which used a lot of mbufs and freed them?
No.
Mbuf clusters may be converted into mbufs; this is in fact a
necessary part of the operation of
the allocator. It doesn't matter whether free memory is "mbufs" or
"mbuf clusters", since the
system needed that many mbufs at one point, it's likely to again.
Converting them back would
just be a waste of time.
= Mike
The problem came up when testing the SCTP KAME implementation which
does not have this
problem on FreeBSD 4.* or 5.*.
Best regards
Michael
On Aug 15, 2005, at 22:12 Uhr, Josh Graessley wrote:
Hello Michael,
I believe that once a cluster is used for mbufs, those mbufs are
never again collecting in to a cluster. Again, it has been some
time since I've mucked with that stuff, so I might be wrong.
It sounds like you're using too many mbufs. You might want to look
in to ways to reduce the number of mbufs in use.
-josh
On Aug 15, 2005, at 12:50 PM, Michael Tuexen wrote:
Hi Josh,
once again thank you very much!
Using your information I was able to find (after a one week
search) a 'mbuf cluster
leak' in the SCTP KAME implementation when the code runs on Mac
OS X.
The point is, that it is no leak. What happens is that when a
program runs it needs
some mbufs. So some clusters are converted to mbufs and the
number of free mbuf
clusters shrinks.
After the program has finished the number of free mbuf clusters
is reduced but the number
of free mbufs is incremented. During tests this resulted in a
scenario where you ran out
of mbuf clusters.
So the question is: How/when are free mbufs put together to free
mbuf clusters again?
Best regards
Michael
On Aug 15, 2005, at 17:24 Uhr, Josh Graessley wrote:
If I remember correctly, mbufs themselves are stored in
clusters. A cluster can be used as a cluster on it's own or it
can be used to store mbufs. An mbuf is a fraction of a cluster.
If the system runs out of mbufs, it may convert a cluster in to
something like 8 mbufs.
-josh
On Aug 15, 2005, at 7:46 AM, Michael Tuexen wrote:
Dear all,
I have a simple question:
Normally a used cluster element is one where there exist an
mbuf which has
a pointer to the cluster element. This happens at least when
you get it with
m_mclget or the corresponding macro. This would than mean that
the number of
uses mbufs is not larger than the number of used mbuf clusters.
But netstat -m gives for example:
[PowerMac:/] tuexen% netstat -m
330 mbufs in use:
325 mbufs allocated to data
1 mbufs allocated to packet headers
3 mbufs allocated to socket names and addresses
1 mbufs allocated to Appletalk data blocks
376/848 mbuf clusters in use
1778 Kbytes allocated to network (46% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Why can it happen that the number of mbuf clusters is larger
than the number of mbufs?
Thank you very much for your help.
Best regards
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden