: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
: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, idl
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 ar
> -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 th
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 a
: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 mem
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)
improvem
> -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
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
>From: "Kelly Yancey"
>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 assumed memory
> 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() mig
: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 me
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)
improve
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
>From: "Kelly Yancey" <[EMAIL PROTECTED]>
>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
>
> 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() mi
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.
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.
John-Mark Gurney 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, I don't b
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/ bz
"Kelly Yancey" 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 sbrk() and return
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
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/ b
"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 ca
d...@flood.ping.uio.no (Dag-Erling Smorgrav) writes:
> "Kelly Yancey" 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,
[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 er
: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: 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 m
> -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
: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 returne
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
> -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 Smorg
> -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&qu
> -Original Message-
> From: Dag-Erling Smorgrav [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 19, 1999 12:39 PM
> To: Kelly Yancey
> Cc: Dag-Erling Smorgrav; [EMAIL PROTECTED]
> Subject: Re: Overcommit and calloc()
>
>
> "Kelly Yancey" <[E
In the last episode (Jul 19), Dag-Erling Smorgrav said:
> "Kelly Yancey" 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, i
"Kelly Yancey" 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 - d...@flood.
t~
FreeBSD - The Power To Serve - http://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: h
"Kelly Yancey" 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;
{
register void *p;
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 se
"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 Sm
>
> 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 some
]~
FreeBSD - The Power To Serve - http://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 PROTECT
"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;
{
>
> 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 som
44 matches
Mail list logo
