[EMAIL PROTECTED] (Dag-Erling Smorgrav) writes:
"Kelly Yancey" [EMAIL PROTECTED] writes:
Ahh...but wouldn't the bzero() touch all of the memory just allocated
functionally making it non-overcommit?
No. If it were an "non-overcomitting malloc", it would return NULL and
set errno to
"Kelly Yancey" [EMAIL PROTECTED] writes:
I don't know how many programs make use of calloc() but would not a more
efficient algorithm be to better integrate it with malloc() such that if
there is a fragment on the heap which can be used, bzero() it and return
that, otherwise, simply call
John-Mark Gurney [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav scribbled this message on Jul 20:
When I allocate memory, I usually intend to put something in it.
There's always the odd struct sockaddr_in which I bzero() before
filling it in, but they're usually on the stack.
and even
Well, bzero could map all memory (outside the boundaries)
to a single zeroed page marked copy on write.
The statistics you could gather might then point out some grossly broken
programs.
Peter
--
Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc.
From: Charles Randall
I have another post on this list which begs the question: if memory given
to us from sbrk() is already zeroed, why zero it again if we don't have
too if we make calloc() smarter, we could save come clock cycles.
Because the memory returned from malloc() might be
Hi,
At 1:28 pm -0400 20/7/99, Kelly Yancey wrote:
[...]
On recent thought though, I seem to recall having read in the 4.4BSD
Daemon book that having the kernel zero memory is not the preferred
practice, but present because when they tried to stop many progrems dies
which assumed memory was
:Hi,
:
:At 1:28 pm -0400 20/7/99, Kelly Yancey wrote:
:[...]
: On recent thought though, I seem to recall having read in the 4.4BSD
:Daemon book that having the kernel zero memory is not the preferred
:practice, but present because when they tried to stop many progrems dies
:which assumed memory
-Original Message-
From: Matthew Dillon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 20, 1999 1:53 PM
To: Kelly Yancey
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: RE: Overcommit and calloc()
I think this would be a waste of time. As I have said, very few
d...@flood.ping.uio.no (Dag-Erling Smorgrav) writes:
Kelly Yancey kby...@alcnet.com writes:
Ahh...but wouldn't the bzero() touch all of the memory just allocated
functionally making it non-overcommit?
No. If it were an non-overcomitting malloc, it would return NULL and
set errno to
Kelly Yancey kby...@alcnet.com writes:
I don't know how many programs make use of calloc() but would not a more
efficient algorithm be to better integrate it with malloc() such that if
there is a fragment on the heap which can be used, bzero() it and return
that, otherwise, simply call
Dag-Erling Smorgrav scribbled this message on Jul 20:
When I allocate memory, I usually intend to put something in it.
There's always the odd struct sockaddr_in which I bzero() before
filling it in, but they're usually on the stack.
and even then, I don't believe in filling sockaddr_in w/
John-Mark Gurney gurne...@efn.org writes:
Dag-Erling Smorgrav scribbled this message on Jul 20:
When I allocate memory, I usually intend to put something in it.
There's always the odd struct sockaddr_in which I bzero() before
filling it in, but they're usually on the stack.
and even then,
Well, bzero could map all memory (outside the boundaries)
to a single zeroed page marked copy on write.
The statistics you could gather might then point out some grossly broken
programs.
Peter
--
Peter Dufault (dufa...@hda.com) Realtime development, Machine control,
HD Associates, Inc.
From: Charles Randall
I have another post on this list which begs the question: if memory given
to us from sbrk() is already zeroed, why zero it again if we don't have
too if we make calloc() smarter, we could save come clock cycles.
Because the memory returned from malloc() might be
From: Kelly Yancey kby...@alcnet.com
Date: Tue, 20 Jul 1999 13:28:21 -0400
On recent thought though, I seem to recall having read in the 4.4BSD
Daemon book that having the kernel zero memory is not the preferred
practice, but present because when they tried to stop many progrems dies
which
Hi,
At 1:28 pm -0400 20/7/99, Kelly Yancey wrote:
[...]
On recent thought though, I seem to recall having read in the 4.4BSD
Daemon book that having the kernel zero memory is not the preferred
practice, but present because when they tried to stop many progrems dies
which assumed memory was
I think this would be a waste of time. As I have said, very few
large allocations use calloc(). Nearly all small allocations come
off the heap. The cost of adding the complexity to calloc to avoid
zeroing the data is not going to be worth the minor (and unnoticeable)
:Hi,
:
:At 1:28 pm -0400 20/7/99, Kelly Yancey wrote:
:[...]
: On recent thought though, I seem to recall having read in the 4.4BSD
:Daemon book that having the kernel zero memory is not the preferred
:practice, but present because when they tried to stop many progrems dies
:which assumed memory
-Original Message-
From: Matthew Dillon [mailto:dil...@apollo.backplane.com]
Sent: Tuesday, July 20, 1999 1:53 PM
To: Kelly Yancey
Cc: crand...@matchlogic.com; freebsd-hackers@FreeBSD.ORG
Subject: Re: RE: Overcommit and calloc()
I think this would be a waste of time. As I
Hi again,
At 10:54 am -0700 20/7/99, Matthew Dillon wrote:
[...]
It should also be noted that unless your system is entirely cpu-bound,
there is no cost to the kernel to zero memory because it pre-zero's
pages in its idle loop.
Thanks to distributed.net, SETI. et al, idle cycles are
:Hi again,
:
:At 10:54 am -0700 20/7/99, Matthew Dillon wrote:
:[...]
:It should also be noted that unless your system is entirely cpu-bound,
:there is no cost to the kernel to zero memory because it pre-zero's
:pages in its idle loop.
:
:Thanks to distributed.net, SETI. et al, idle
On the other hand, I find the discussion about the merits of overcommit
and the (albeit not always in-depth) explanations of the FreeBSD VM system
educational. It would be nice if would could just extract the small amount
of signal from this discussion and put it into documentation
"Kelly Yancey" [EMAIL PROTECTED] writes:
I'm afraid my question got lost amongst the see of overcommit messages. :)
I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
://www.freebsd.org/
Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD
-Original Message-
From: Dag-Erling Smorgrav [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 19, 1999 12:07 PM
To: Kelly Yancey
Cc: [EMAIL PROTECTED]
Subject: Re: Overcommit and calloc()
"Kelly Y
"Kelly Yancey" [EMAIL PROTECTED] writes:
Ahh...but wouldn't the bzero() touch all of the memory just allocated
functionally making it non-overcommit?
No. If it were an "non-overcomitting malloc", it would return NULL and
set errno to ENOMEM, instead of dumping core.
DES
--
Dag-Erling
In the last episode (Jul 19), Dag-Erling Smorgrav said:
"Kelly Yancey" [EMAIL PROTECTED] writes:
Ahh...but wouldn't the bzero() touch all of the memory just
allocated functionally making it non-overcommit?
No. If it were an "non-overcomitting malloc", it would return NULL
and set errno
-Original Message-
From: Dan Nelson [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 19, 1999 12:55 PM
To: Dag-Erling Smorgrav
Cc: Kelly Yancey; [EMAIL PROTECTED]
Subject: Re: Overcommit and calloc()
In the last episode (Jul 19), Dag-Erling Smorgrav said:
"Kelly Yancey&qu
From: Kelly Yancey [mailto:[EMAIL PROTECTED]]
I have another post on this list which begs the question: if memory given
to us fro sbrk() is already zeroed, why zero it again if we don't have
too if we make calloc() smarter, we could save come clock cycles.
Because the memory returned from
:From: Kelly Yancey [mailto:[EMAIL PROTECTED]]
:I have another post on this list which begs the question: if memory given
:to us fro sbrk() is already zeroed, why zero it again if we don't have
:too if we make calloc() smarter, we could save come clock cycles.
:
:Because the memory returned
On the other hand, I find the discussion about the merits of overcommit
and the (albeit not always in-depth) explanations of the FreeBSD VM system
educational. It would be nice if would could just extract the small amount
of signal from this discussion and put it into documentation
Kelly Yancey kby...@alcnet.com writes:
I'm afraid my question got lost amongst the see of overcommit messages. :)
I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
://www.freebsd.org/
Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD
-Original Message-
From: Dag-Erling Smorgrav [mailto:d...@flood.ping.uio.no]
Sent: Monday, July 19, 1999 12:07 PM
To: Kelly Yancey
Cc: hack...@freebsd.org
Subject: Re: Overcommit and calloc()
Kelly
Kelly Yancey kby...@alcnet.com writes:
Ahh...but wouldn't the bzero() touch all of the memory just allocated
functionally making it non-overcommit?
No. If it were an non-overcomitting malloc, it would return NULL and
set errno to ENOMEM, instead of dumping core.
DES
--
Dag-Erling Smorgrav -
In the last episode (Jul 19), Dag-Erling Smorgrav said:
Kelly Yancey kby...@alcnet.com writes:
Ahh...but wouldn't the bzero() touch all of the memory just
allocated functionally making it non-overcommit?
No. If it were an non-overcomitting malloc, it would return NULL
and set errno to
-Original Message-
From: Dag-Erling Smorgrav [mailto:d...@flood.ping.uio.no]
Sent: Monday, July 19, 1999 12:39 PM
To: Kelly Yancey
Cc: Dag-Erling Smorgrav; freebsd-hackers@freebsd.org
Subject: Re: Overcommit and calloc()
Kelly Yancey kby...@alcnet.com writes:
Ahh
-Original Message-
From: Dan Nelson [mailto:dnel...@emsphone.com]
Sent: Monday, July 19, 1999 12:55 PM
To: Dag-Erling Smorgrav
Cc: Kelly Yancey; freebsd-hackers@FreeBSD.ORG
Subject: Re: Overcommit and calloc()
In the last episode (Jul 19), Dag-Erling Smorgrav said:
Kelly Yancey
From: Kelly Yancey [mailto:kby...@alcnet.com]
I have another post on this list which begs the question: if memory given
to us fro sbrk() is already zeroed, why zero it again if we don't have
too if we make calloc() smarter, we could save come clock cycles.
Because the memory returned from
:From: Kelly Yancey [mailto:kby...@alcnet.com]
:I have another post on this list which begs the question: if memory given
:to us fro sbrk() is already zeroed, why zero it again if we don't have
:too if we make calloc() smarter, we could save come clock cycles.
:
:Because the memory returned
38 matches
Mail list logo
