| Author |
Message |
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
 Posted: Fri Apr 12, 2002 5:29 pm Post subject:
Re: Removing limits from malloc(9)
|
|
|
On 12-Apr-2002 Garance A Drosihn wrote:
| Quote: | At 1:58 AM -0400 4/12/02, Jeff Roberson wrote:
This is more along the lines of what I was looking for. I
don't like the limits but I wasn't sure if anyone found them
to be useful. So far I have heard 2 votes for getting rid
of limits, and no votes for keeping them.
My earlier comment was meant to be a weak vote for the limits.
"weak" in the sense that I would like to keep them, but that
I do not feel very strongly about it. Consider it more like
half-a-vote for them. Even with that, I wouldn't mind if limits
were only available as a malloc option (set via /etc/malloc.conf)
and not done by default.
|
These are limits for kernel malloc(9), not userland malloc(3).
These two malloc's are entirely unrelated.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Fri Apr 12, 2002 4:19 pm Post subject:
Re: Removing limits from malloc(9)
|
|
|
At 1:29 PM -0400 4/12/02, John Baldwin wrote:
| Quote: | On 12-Apr-2002 Garance A Drosihn wrote:
At 1:58 AM -0400 4/12/02, Jeff Roberson wrote:
This is more along the lines of what I was looking for. I
don't like the limits but I wasn't sure if anyone found them
to be useful. So far I have heard 2 votes for getting rid
of limits, and no votes for keeping them.
My earlier comment was meant to be a weak vote for the limits.
"weak" in the sense that I would like to keep them, but that
I do not feel very strongly about it. Consider it more like
half-a-vote for them. Even with that, I wouldn't mind if limits
were only available as a malloc option (set via /etc/malloc.conf)
and not done by default.
These are limits for kernel malloc(9), not userland malloc(3).
These two malloc's are entirely unrelated.
|
Ah. Okay, reduce my vote to 1/10th of a vote for limits... :-)
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Fri Apr 12, 2002 3:19 pm Post subject:
Re: Removing limits from malloc(9)
|
|
|
At 1:58 AM -0400 4/12/02, Jeff Roberson wrote:
| Quote: | This is more along the lines of what I was looking for. I
don't like the limits but I wasn't sure if anyone found them
to be useful. So far I have heard 2 votes for getting rid
of limits, and no votes for keeping them.
|
My earlier comment was meant to be a weak vote for the limits.
"weak" in the sense that I would like to keep them, but that
I do not feel very strongly about it. Consider it more like
half-a-vote for them. Even with that, I wouldn't mind if limits
were only available as a malloc option (set via /etc/malloc.conf)
and not done by default.
Perhaps just file these comments under "nice ideas to do someday",
and just ignore them for now...
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Jeff Roberson
*nix forums Guru Wannabe
Joined: 08 Apr 2002
Posts: 107
|
| Posted: Fri Apr 12, 2002 5:58 am Post subject:
Re: Removing limits from malloc(9)
|
|
|
On Thu, 11 Apr 2002, Peter Wemm wrote:
| Quote: | Personally, I'd be happy with counts being done per-cpu (to avoid
contention) and aggregated periodically (eg: at vmstat -m time). And to
hell with the limits. But that's just me. :-)
|
This is more along the lines of what I was looking for. I don't like the
limits but I wasn't sure if anyone found them to be useful. So far I have
heard 2 votes for getting rid of limits, and no votes for keeping them.
Would anyone else care to vote?
Thanks,
Jeff
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Peter Wemm
*nix forums Guru Wannabe
Joined: 11 Apr 2002
Posts: 113
|
| Posted: Thu Apr 11, 2002 9:02 am Post subject:
Re: Removing limits from malloc(9)
|
|
|
Wes Peters wrote:
| Quote: | Dag-Erling Smorgrav wrote:
Jeff Roberson <jroberson@chesapeake.net> writes:
The last bit that is missing before we can call malloc/free w/o Giant is
the malloc_type statistics. Currently there is nothing really protecting
them. There really is no lock that they can conveniently live under. I
have a few options. The one that I'm leaning towards is only enabling
malloc_type statistics if INVARIANTS is compiled in. Then I could make
one lock per malloc_type. The reason this shouldn't be the default is
because it creates a single point of contention which is in sharp contras
t
with the rest of the allocator.
It's still a lot better than Giant, and it's a leaf lock so there
shouldn't be any worries about reversal. I'd go for it if I were you.
Can they be updated with an atomic increment? For statistics like this,
being off by 1 or 2 on read isn't so important as long as you don't miss
a bunch of counts.
|
You know, at work the one and only time we ever check malloc limits is when
we discover that a transient load spike caused it to hit some limit and it
crashed or locked up as a result. When the machine crashes or deadlocks
automatically as a result of hitting the limits, one has to wonder what the
point is? It is crashing in order to protect us from what? crashing?
Personally, I'd be happy with counts being done per-cpu (to avoid
contention) and aggregated periodically (eg: at vmstat -m time). And to
hell with the limits. But that's just me. :-)
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Jeff Roberson
*nix forums Guru Wannabe
Joined: 08 Apr 2002
Posts: 107
|
| Posted: Wed Apr 10, 2002 9:18 am Post subject:
Re: Removing limits from malloc(9)
|
|
|
On Tue, 9 Apr 2002, Wes Peters wrote:
| Quote: | Dag-Erling Smorgrav wrote:
It's still a lot better than Giant, and it's a leaf lock so there
shouldn't be any worries about reversal. I'd go for it if I were you.
Can they be updated with an atomic increment? For statistics like this,
being off by 1 or 2 on read isn't so important as long as you don't miss
a bunch of counts.
|
An atomic increment would still cause cache thrashing. I considered doing
per cpu queues for the statistics and then aggregating them when someone
wants to report them. This doesn't work if you want to do limits though,
since you'd need to check all of the statistics caches at each call. I
suppose that this is really good enough at this point. Maybe when we're
running on 64 or 128 CPU systems the cache thrashing will hurt enough to
get rid of limits.  Until then I'll just leave them the way they are
and wrap the whole thing in a per malloc_type mutex. This should
sufficiently reduce contention and make malloc(9) totally mp safe.
Jeff
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Wes Peters
*nix forums addict
Joined: 09 Apr 2002
Posts: 90
|
| Posted: Tue Apr 09, 2002 9:56 pm Post subject:
Re: Removing limits from malloc(9)
|
|
|
Dag-Erling Smorgrav wrote:
| Quote: |
Jeff Roberson <jroberson@chesapeake.net> writes:
The last bit that is missing before we can call malloc/free w/o Giant is
the malloc_type statistics. Currently there is nothing really protecting
them. There really is no lock that they can conveniently live under. I
have a few options. The one that I'm leaning towards is only enabling
malloc_type statistics if INVARIANTS is compiled in. Then I could make
one lock per malloc_type. The reason this shouldn't be the default is
because it creates a single point of contention which is in sharp contrast
with the rest of the allocator.
It's still a lot better than Giant, and it's a leaf lock so there
shouldn't be any worries about reversal. I'd go for it if I were you.
|
Can they be updated with an atomic increment? For statistics like this,
being off by 1 or 2 on read isn't so important as long as you don't miss
a bunch of counts.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Mon Apr 08, 2002 7:37 pm Post subject:
Re: Removing limits from malloc(9)
|
|
|
At 4:25 AM -0400 4/8/02, Jeff Roberson wrote:
| Quote: | The last bit that is missing before we can call malloc/free w/o
Giant is the malloc_type statistics. [...] I have a few options.
The one that I'm leaning towards is only enabling malloc_type
statistics if INVARIANTS is compiled in. Then I could make one
lock per malloc_type.
|
Why would this be tied to INVARIANTS? That option is described
as "enable sanity checks". Would it make more sense to have a
different kernel option, called MALLOC_STATS or something? Maybe
have that as a sysctl, or at least a loader-tunable value?
or maybe even an /etc/malloc.conf option...
| Quote: | So, the INVARIANTS only option doesn't work if we want to keep
malloc type limits. I'm wondering how useful this has been in
the past? I have heard from phk that it is useful for md(4)
which could be converted to use a zone. Is there any real need
for these limits other than that?
|
I would like the option of malloc type limits to remain available,
although it would be alright if it's only available as some option.
I have a feeling that there is something about this that I'm
missing, though...
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Dag-Erling Smorgrav
*nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
| Posted: Mon Apr 08, 2002 8:25 am Post subject:
Re: Removing limits from malloc(9)
|
|
|
Jeff Roberson <jroberson@chesapeake.net> writes:
| Quote: | The last bit that is missing before we can call malloc/free w/o Giant is
the malloc_type statistics. Currently there is nothing really protecting
them. There really is no lock that they can conveniently live under. I
have a few options. The one that I'm leaning towards is only enabling
malloc_type statistics if INVARIANTS is compiled in. Then I could make
one lock per malloc_type. The reason this shouldn't be the default is
because it creates a single point of contention which is in sharp contrast
with the rest of the allocator.
|
It's still a lot better than Giant, and it's a leaf lock so there
shouldn't be any worries about reversal. I'd go for it if I were you.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Jeff Roberson
*nix forums Guru Wannabe
Joined: 08 Apr 2002
Posts: 107
|
| Posted: Mon Apr 08, 2002 8:25 am Post subject:
Removing limits from malloc(9)
|
|
|
The last bit that is missing before we can call malloc/free w/o Giant is
the malloc_type statistics. Currently there is nothing really protecting
them. There really is no lock that they can conveniently live under. I
have a few options. The one that I'm leaning towards is only enabling
malloc_type statistics if INVARIANTS is compiled in. Then I could make
one lock per malloc_type. The reason this shouldn't be the default is
because it creates a single point of contention which is in sharp contrast
with the rest of the allocator.
So, the INVARIANTS only option doesn't work if we want to keep malloc type
limits. I'm wondering how useful this has been in the past? I have heard
from phk that it is useful for md(4) which could be converted to use a
zone. Is there any real need for these limits other than that?
Any comments? Suggestions?
Thanks!
Jeff
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
