Replying to myself...
You'd have to be able to specify the absolute maximum memory use for
a process to ensure you'd still kill run-aways (These would go first!
regardless of the other rules maybe).
Matthew Thyer wrote:
>
> There is obviously a problem when all swap is exhausted.
>
> The only s
There is obviously a problem when all swap is exhausted.
The only solution is to allow the additional memory *use* to succeed AND
to warn the sysadmin that ALL virtual memory has been exhausted.
The only way to do this is to be able to allocate extra virtual memory.
I'd vote for a system that wou
In message , Snob Art Gen
re writes:
>On Thu, 15 Apr 1999, Don Lewis wrote:
>
>> SunOS 4 doesn't do memory overcommit.
>
>I get the impression from Vahalia's _UNIX Internals_ that this is true
>of SunOS 5 as well.
I know from experience that solaris 2.4 overcommits.
--
Poul-Henning Kamp
On Thu, 15 Apr 1999, Don Lewis wrote:
> SunOS 4 doesn't do memory overcommit.
I get the impression from Vahalia's _UNIX Internals_ that this is true
of SunOS 5 as well.
> This could be shaved down a bit if SunOS didn't require
> (swap > total VM) instead of (swap + RAM > total VM).
Again, from
On Apr 14, 4:40pm, Chuck Robey wrote:
} Subject: Re: swap-related problems
} On Wed, 14 Apr 1999, Anthony Kimball wrote:
} > Well, it's only needed if you want to be able to reliably execute ANSI
} > C code according to spec. I personally don't care. I'd be surprised
} &g
On Apr 15, 12:14pm, Peter Jeremy wrote:
} Subject: Re: swap-related problems
} Mikhail Teterin wrote:
} > Worse then that,
} >it may be possible to use it at malloc time, but unless your program
} >runs and touches every page, the memory may not be available later.
}
} If you run and to
Just a quick note... I've heard 'vfork' and 'fork' mentioned twice now.
I think there is some confusion. fork() does not really eat that
much memory if all you are doing is fork/exec. The only difference
between fork and vfork from a resource point of view is around 32 KBytes
Mike Smith once wrote:
> > >A signal handler is not guaranteed to work. It must be written
> > >such that it does not require a new page of memory. Some possible
> > >problems here are the stack growing, writing on a new page in the
> > >data segment, etc.
> >
> > man sigaltstack
> That doesn't
Mike Smith writes:
> > Jim Bloom wrote:
> > >
> > >A signal handler is not guaranteed to work. It must be written such that
> > >it
> > >does not require a new page of memory. Some possible problems here are the
> > >stack growing, writing on a new page in the data segment, etc.
> >
> > man si
> Jim Bloom wrote:
> >
> >A signal handler is not guaranteed to work. It must be written such that it
> >does not require a new page of memory. Some possible problems here are the
> >stack growing, writing on a new page in the data segment, etc.
>
> man sigaltstack
That doesn't help; there is
( Sitting in the bleachers )
Ra! Ra! Ra!
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Quoth Daniel C. Sobral on Thu, 15 April:
:
: FreeBSD executes ANSI C code reliably according to spec, as long as
: there is enough memory in the system. If there isn't, FreeBSD
: doesn't run reliably, much less executes any kind of code reliably.
:
I understand this. I concieve the purpose of th
Jim Bloom wrote:
>
>A signal handler is not guaranteed to work. It must be written such that it
>does not require a new page of memory. Some possible problems here are the
>stack growing, writing on a new page in the data segment, etc.
man sigaltstack
Tony.
--
f.a.n.finch d...@dotat.at f.
Brian Feldman wrote:
>
> mlock()? BTW, why can't anyone explain why the old behavior WAS THAT
> the process would get NULL? Now it's this...
Maybe the login class was changed, and now has no limits, or a high
enough limit that the resources are exhausted.
--
Daniel C. Sobral
Anthony Kimball wrote:
>
> Quoth Poul-Henning Kamp on Wed, 14 April:
> :
> : 1. Demonstrate the need.
>
> Well, it's only needed if you want to be able to reliably execute ANSI
> C code according to spec. I personally don't care. I'd be surprised
> if core didn't though. I would suspect that i
Anthony Kimball wrote:
>
> Quoth Daniel C. Sobral on Thu, 15 April:
> :
> : As soon as this application grabs all the memory, the next thing to
> : request more memory (not a malloc!) will cause the application to be
> : killed (largest application criteria). Change the criteria, and
> : *another*
>> Sorry FreeBSD doesn't support resource reservation for memory.
>
>mlock()? BTW, why can't anyone explain why the old behavior WAS THAT
>the process would get NULL? Now it's this...
Implementation quirks (bugs) and races.
brk(2) used to fail when memory (real+swap) is running short, instead
of
Mikhail Teterin wrote:
>That's my point! I advocate the use of some _other_ signal. Something
>catchable.
As soon as you allow a catchable signal, you create a potential
deadlock situation. See my previous mail.
>In case of "resource shortage" the malloc should be unsuccessful
>and return NULL.
Anthony Kimball wrote:
>
> : > All I want is that a program gets NULL from malloc if there is no memory
> : > available. I find that to be a very fundamental thing about malloc.
>
> : Do you have a solution? We don't.
>
> Make an sbrk variant which will pre-allocate backing store.
> setenv MALLO
Warner Losh once stated:
=: Then, one can write a safe malloc, which will install the signal
=: handler, and touch every page in the the memory referenced by the
=: to-be-returned pointer. If the signal handler is invoked in the
=: progress, the to-be-returned memory must be returned back to the
=
In message <199904142340.taa96...@misha.cisco.com> Mikhail Teterin writes:
: Then, one can write a safe malloc, which will install the signal
: handler, and touch every page in the the memory referenced by the
: to-be-returned pointer. If the signal handler is invoked in the
: progress, the to-be-r
Quoth Brian Feldman on Wed, 14 April:
:
: ACTUALLY it would still break ANSI because the malloc itself would crash
: the program, instead of touching the memory manually.
The point here is that malloc can return null when it fails to allocate.
I might mention that Andrew Reilly's suggestion is th
Mikhail Teterin wrote:
> Worse then that,
>it may be possible to use it at malloc time, but unless your program
>runs and touches every page, the memory may not be available later.
If you run and touch every page, you are guaranteed to have the
memory available, but you also increase the chances
> I'm not doing this, damnit ;)
Then can we end this stupid thread already?
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
On Wed, 14 Apr 1999, Anthony Kimball wrote:
> Quoth Poul-Henning Kamp on Wed, 14 April:
> :
> : 1. Demonstrate the need.
>
> Well, it's only needed if you want to be able to reliably execute ANSI
> C code according to spec. I personally don't care. I'd be surprised
> if core didn't though. I
A signal handler is not guaranteed to work. It must be written such that it
does not require a new page of memory. Some possible problems here are the
stack growing, writing on a new page in the data segment, etc. I'm not familiar
enough with the VM system, but if you couldn't create a new swap
On Wed, 14 Apr 1999, Poul-Henning Kamp wrote:
> In message <14100.61923.427423.153...@avalon.east>, Anthony Kimball writes:
> >
> >: > All I want is that a program gets NULL from malloc if there is no memory
> >: > available. I find that to be a very fundamental thing about malloc.
> >
> >: Do you
On Wed, Apr 14, 1999 at 01:12:00PM -0400, a little birdie told me
that Mikhail Teterin remarked
>
> Aha, now its clearer. May be, since we are do not conform anyway,
> we can design some clever way of notifying a program rather then
> SIGKILL-ing it?
>
> Perhaps, SIGBUS? Something, a program can
On Wed, 14 Apr 1999, Poul-Henning Kamp wrote:
> In message <199904141501.laa25...@kot.ne.mediaone.net>, Mikhail Teterin
> writes:
> >Poul-Henning Kamp once stated:
> >
> >=malloc() on FreeBSD returns NULL when it cannot allocate the memory
> >=asked for.
> >
> >=If you have an example where this
> I do not see how they can guarantee the usability of the returned
> memory with the current kernel. There apparently is no way of
> knowing at malloc time if the memory can be used. Worse then that,
> it may be possible to use it at malloc time, but unless your program
> runs and touches every p
On Wed, 14 Apr 1999, Mikhail Teterin wrote:
> Steve Kargl once wrote:
>
> > /usr/ports/devel/libxalloc
> > /usr/ports/devel/libmalloc
> > /usr/ports/devel/libdlmalloc
>
> I do not see how they can guarantee the usability of the returned
> memory with the current kernel. There apparently is no wa
Steve Kargl once wrote:
> Then, submit your patches to fix the problem preferably with a knob to
> turn your patches on/off. From the discussion, I hope you're prepared
> to deal with the following scenario:
I'll be prepared... I don't think it should be a compile time option,
though. May be ker
On Thu, 15 Apr 1999, Andrew Reilly wrote:
> On Wed, Apr 14, 1999 at 02:55:27PM -0500, Anthony Kimball wrote:
> >
> > : > All I want is that a program gets NULL from malloc if there is no memory
> > : > available. I find that to be a very fundamental thing about malloc.
> >
> > : Do you have a so
Mikhail Teterin wrote:
> Sheldon Hearn once wrote:
>
> > > : 3. Send patches.
> > >
> > > And I certainly don't care enough to do that!-)
>
> > So, what? You're just arguing for fun? If so, then you and everyone
> > else doing like wise can just piss the hell off.
>
> I, for one, was arguing be
Sheldon Hearn once wrote:
> > : 3. Send patches.
> >
> > And I certainly don't care enough to do that!-)
> So, what? You're just arguing for fun? If so, then you and everyone
> else doing like wise can just piss the hell off.
I, for one, was arguing because I saw a number of people ask about
th
On Wed, Apr 14, 1999 at 02:55:27PM -0500, Anthony Kimball wrote:
>
> : > All I want is that a program gets NULL from malloc if there is no memory
> : > available. I find that to be a very fundamental thing about malloc.
>
> : Do you have a solution? We don't.
>
> Make an sbrk variant which will
Quoth Sheldon Hearn on Thu, 15 April:
:
: > : 3. Send patches.
: >
: > And I certainly don't care enough to do that!-)
:
: So, what? You're just arguing for fun? If so, then you and everyone else
: doing like wise can just piss the hell off.
[redirected to chat]
No, I'm trying to contribute co
On Wed, 14 Apr 1999 15:22:22 EST, Anthony Kimball wrote:
> : 3. Send patches.
>
> And I certainly don't care enough to do that!-)
So, what? You're just arguing for fun? If so, then you and everyone else
doing like wise can just piss the hell off.
Ciao,
Sheldon.
To Unsubscribe: send mail to
Quoth Chuck Robey on Wed, 14 April:
: ... just so the one guy to
: complain *at all*
Someone is always the first person to recognize a defect. Until
others do, they stand alone.
: ...can not lose sleep over something that has causes no
: problems at all with any ANSI code in a properly sized sy
On Wed, 14 Apr 1999, Anthony Kimball wrote:
> Quoth Poul-Henning Kamp on Wed, 14 April:
> :
> : 1. Demonstrate the need.
>
> Well, it's only needed if you want to be able to reliably execute ANSI
> C code according to spec. I personally don't care. I'd be surprised
> if core didn't though. I
Quoth Poul-Henning Kamp on Wed, 14 April:
:
: 1. Demonstrate the need.
Well, it's only needed if you want to be able to reliably execute ANSI
C code according to spec. I personally don't care. I'd be surprised
if core didn't though. I would suspect that it would be deemed worthy
of someone's p
In message <14100.61923.427423.153...@avalon.east>, Anthony Kimball writes:
>
>: > All I want is that a program gets NULL from malloc if there is no memory
>: > available. I find that to be a very fundamental thing about malloc.
>
>: Do you have a solution? We don't.
>
>Make an sbrk variant which w
: > All I want is that a program gets NULL from malloc if there is no memory
: > available. I find that to be a very fundamental thing about malloc.
: Do you have a solution? We don't.
Make an sbrk variant which will pre-allocate backing store.
setenv MALLOC_PREALLOCATE
Not so hard.
To Unsubs
Ladavac Marino once wrote:
> [ML] Sadly, in the memory overcommit situation, there is no way to
> know whether a pointer returned by malloc will cause a process demise
> or not. The pointer is valid, but the swap area mapping is defered
> until the page is dirtied (basically, the pointer points t
> -Original Message-
> From: Mikhail Teterin [SMTP:m...@kot.ne.mediaone.net]
> Sent: Wednesday, April 14, 1999 5:01 PM
> To: curr...@freebsd.org
> Subject: Re: swap-related problems
>
> They then, rightfully exclaimed:
>
> . but should not mal
> -Original Message-
> From: Daniel C. Sobral [SMTP:d...@newsguy.com]
> Sent: Wednesday, April 14, 1999 3:04 PM
> To: Ladavac Marino
> Cc: 'm...@aldan.algebra.com'; curr...@freebsd.org
> Subject: Re: swap-related problems
>
> Ladavac Mari
In message <199904141501.laa25...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Poul-Henning Kamp once stated:
>
>=malloc() on FreeBSD returns NULL when it cannot allocate the memory
>=asked for.
>
>=If you have an example where this is not the case I would VERY
>=much like to see it.
>
>I believe
Poul-Henning Kamp once stated:
=malloc() on FreeBSD returns NULL when it cannot allocate the memory
=asked for.
=If you have an example where this is not the case I would VERY
=much like to see it.
I believe, a number of examples were given, when the use of the non-NULL
pointer returned by mallo
In message <199904141314.jaa24...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Poul-Henning Kamp once stated:
>
>=>Well, this is just an implementation detail, is not it? I don't
>=>mean to critisize, or anything, but such thing as "no available
>=>memory" is a fairly intuitive... Coming down, ag
Mikhail Teterin wrote:
>
> All I want is that a program gets NULL from malloc if there is no memory
> available. I find that to be a very fundamental thing about malloc.
>
> In response, me and others are told at different times:
>
> . there is no such thing as "no memory available" (!!!
Chuck Robey once stated:
=He's not talking about an artificial limit, he's talking about another
=user making off with all the memory. This sounds very bizarre, how can
=you possibly ask the system to predict what other user's are going to
=ask for, in advance? You can't possibly get absolute pe
On Wed, 14 Apr 1999, Mikhail Teterin wrote:
> Poul-Henning Kamp once stated:
>
> =>Well, this is just an implementation detail, is not it? I don't
> =>mean to critisize, or anything, but such thing as "no available
> =>memory" is a fairly intuitive... Coming down, again, the malloc
> =>should ret
Ladavac Marino wrote:
>
> Another strategy is to reserve the swap space as soon as it is
> allocated by the program. This strategy is much more conservative and
> inherently safer, but it needs much more space: for instance, if you
> have a program with WSS of a gigabyte and you want to s
Poul-Henning Kamp once stated:
=>Well, this is just an implementation detail, is not it? I don't
=>mean to critisize, or anything, but such thing as "no available
=>memory" is a fairly intuitive... Coming down, again, the malloc
=>should return a usable memory if available and NULL if it's not.
=>
On Wed, 14 Apr 1999, Poul-Henning Kamp wrote:
> In message <199904132245.saa93...@misha.cisco.com>, Mikhail Teterin writes:
> >Poul-Henning Kamp once wrote:
>
> >Well, this is just an implementation detail, is not it? I don't
> >mean to critisize, or anything, but such thing as "no available
> >m
On Wed, 14 Apr 1999, Alfred Perlstein wrote:
> On Wed, 14 Apr 1999, Ladavac Marino wrote:
>
> > > -Original Message-
> > > From: Mikhail Teterin [SMTP:m...@misha.cisco.com]
> > > Sent: Wednesday, April 14, 1999 12:45 AM
> > > To: cu
In message <199904132245.saa93...@misha.cisco.com>, Mikhail Teterin writes:
>Poul-Henning Kamp once wrote:
>Well, this is just an implementation detail, is not it? I don't
>mean to critisize, or anything, but such thing as "no available
>memory" is a fairly intuitive... Coming down, again, the mal
On Wed, 14 Apr 1999, Ladavac Marino wrote:
> > -Original Message-
> > From: Mikhail Teterin [SMTP:m...@misha.cisco.com]
> > Sent: Wednesday, April 14, 1999 12:45 AM
> > To: curr...@freebsd.org
> > Subject:Re: swap-related problems
>
> -Original Message-
> From: Mikhail Teterin [SMTP:m...@misha.cisco.com]
> Sent: Wednesday, April 14, 1999 12:45 AM
> To: curr...@freebsd.org
> Subject: Re: swap-related problems
>
>
> Well, this is just an implementation detail, is not it? I don't
>
Poul-Henning Kamp once wrote:
> >> If you unset the datasize limit and the program does not exceed
> >> the maximum system-supported datasize limit, malloc() should
> >> not return NULL even if the system is out of swap.
> >Can you explain why? Our malloc(3) is a little fuzzy as to th
In message <199904121505.laa70...@misha.cisco.com>, Mikhail Teterin writes:
>Matthew Dillon once wrote:
>
>> If you unset the datasize limit and the program does not exceed
>> the maximum system-supported datasize limit, malloc() should not
>> return NULL even if the system is out of s
It seems to me that you might kill the forst program the has a lot of ram
in unse that has not specified a limit for itself.. programs that are wel
enough behaved to set a limit for themselves should be rewarded.
just a thought...
julian
On Sun, 11 Apr 1999, Matthew Dillon wrote:
> :I use the m
Matthew Dillon once wrote:
> If you unset the datasize limit and the program does not exceed
> the maximum system-supported datasize limit, malloc() should not
> return NULL even if the system is out of swap.
Can you explain why? Our malloc(3) is a little fuzzy as to the
circumstance
:>
:> I ran your program. malloc() appears to work properly -- returns NULL
when
:> the datasize limit is reached. In my case, I set the datasize limit
:> to 64MB and ran the program.
:
:Unset the datasize limit. Now what happens? It used to return NULL, now
:it gets SIGKILLed. Ser
On Sun, 11 Apr 1999, Matthew Dillon wrote:
> :I use the memory as soon as it's malloced. If it reserves a page, then
> :pagefaults it into existence, the VM system knows that that page is now
> :allocated. When I malloc the last available page for user use, the VM
> :system knows that it's the las
:I use the memory as soon as it's malloced. If it reserves a page, then
:pagefaults it into existence, the VM system knows that that page is now
:allocated. When I malloc the last available page for user use, the VM
:system knows that it's the last page. I dirty it, and there are none
:free. If I m
On Sun, 11 Apr 1999, Matthew Dillon wrote:
> :It seems that something has broken the good ol' swap behavior. For instance,
> :I have my user-limits set to unlimited and I run something which uses up
> :all RAM. Mallocing never FAILS in the program, as brk() doesn't fail, as etc
> :etc etc. But mal
:It seems that something has broken the good ol' swap behavior. For instance,
:I have my user-limits set to unlimited and I run something which uses up
:all RAM. Mallocing never FAILS in the program, as brk() doesn't fail, as etc
:etc etc. But mallocing continues, all swap space gets used, and both
68 matches
Mail list logo
