Seems like failing system calls (mmap and sbrk) that allocate memory is more
graceful and would allow the program to at least issue the reasonable
error message.
And more intelligent programs would be able to reduce used memory
instead of just dying.
Yuri
On Wed, 20 May 2009, Yuri wrote:
Seems like failing system calls (mmap and sbrk) that allocate memory is more
graceful and would allow the program to at least issue the reasonable error
message.
And more intelligent programs would be able to reduce used memory instead of
just dying.
It's a
Because the kernel is lazy!!
You can google for lazy algorithm, or find an OS internals book and
read about the advantages of doing it this way...
Rayson
On Thu, May 21, 2009 at 1:32 AM, Yuri y...@rawbw.com wrote:
Seems like failing system calls (mmap and sbrk) that allocate memory is more
+--- Yuri, 2009-05-20 ---
| Seems like failing system calls (mmap and sbrk) that allocate memory is more
| graceful and would allow the program to at least issue the reasonable
| error message.
| And more intelligent programs would be able to reduce used memory
| instead of just dying.
Nate Eldredge neldre...@math.ucsd.edu wrote:
For instance, consider the following program.
snip
this happens most of the time with fork() ...
It may be worthwhile to point out that one extremely common case is
the shell itself. Even /bin/sh is large; csh (the default FreeBSD
shell) is quite a
Hi.
How do I compile the system binutils (contrib/binutils) as i386 -
x86_64 cross utils? That is, binutils that will run on an i386 host but
will produce x86_64 binaries?
I'm trying to produce a bootstrapping compiler for a port and need to
get these working. I've spent a while reading
On Thu, 21 May 2009, xorquew...@googlemail.com wrote:
How do I compile the system binutils (contrib/binutils) as i386 - x86_64
cross utils? That is, binutils that will run on an i386 host but will
produce x86_64 binaries?
I'm trying to produce a bootstrapping compiler for a port and need to
On 2009-05-21 11:20:21, Robert Watson wrote:
Not really my area, but if you haven't found make toolchain and make
buildenv then you might want to take a look. Typically these will be
combined with TARGET_ARCH=foo, and in your case foo is 'amd64'. The
former builds the toolchain required
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 May 2009 10:53:05 +0100
xorquew...@googlemail.com mentioned:
Hi.
How do I compile the system binutils (contrib/binutils) as i386 -
x86_64 cross utils? That is, binutils that will run on an i386 host but
will produce x86_64 binaries?
On Thu, 21 May 2009, per...@pluto.rain.com wrote:
Nate Eldredge neldre...@math.ucsd.edu wrote:
With overcommit, we pretend to give the child a writable private
copy of the buffer, in hopes that it won't actually use more of it
than we can fulfill with physical memory.
I am about 99% sure
On 2009-05-21 16:10:18, Stanislav Sedov wrote:
You can also try using devel/cross-binutils to build cross-tools for
x86_64-freebsd. Random people reported they're working fine.
Unfortunately, as noted in this thread:
http://marc.info/?l=freebsd-hackersm=124146166902690w=2
Using that port
Robert Watson wrote:
On Thu, 21 May 2009, xorquew...@googlemail.com wrote:
How do I compile the system binutils (contrib/binutils) as i386 -
x86_64 cross utils? That is, binutils that will run on an i386 host
but will produce x86_64 binaries?
I'm trying to produce a bootstrapping compiler
Nate Eldredge wrote:
Suppose we run this program on a machine with just over 1 GB of
memory. The fork() should give the child a private copy of the 1 GB
buffer, by setting it to copy-on-write. In principle, after the
fork(), the child might want to rewrite the buffer, which would
require an
On Thu, May 21, 2009 at 10:52:26AM -0700, Yuri wrote:
Nate Eldredge wrote:
Suppose we run this program on a machine with just over 1 GB of
memory. The fork() should give the child a private copy of the 1 GB
buffer, by setting it to copy-on-write. In principle, after the
fork(), the child
i succeeded with putting 8-current snap on a pen and booting. but i can
not figure out how to tell it to use the pen drive for system image
loads.
do i have to back off to 7 and then upgrade forward after install?
rndy
___
freebsd-hackers@freebsd.org
On Thu, 21 May 2009, Yuri wrote:
Nate Eldredge wrote:
Suppose we run this program on a machine with just over 1 GB of memory. The
fork() should give the child a private copy of the 1 GB buffer, by
setting it to copy-on-write. In principle, after the fork(), the child
might want to rewrite
Alfred Perlstein wrote:
* Chuck Robey chu...@telenix.org [090518 13:03] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been googling, trying to see if I can find notes regarding what needs
changing, in what order, to adapt the FreeBSD kernel to a new processor.
Anyone
know
I got instructions from Warner about how to build my crosstools (the FreeBSD
ones) and after a minor startup contretemps, things began to work better. My
problem is that on doing the linking step, I'm getting a complaint that it can't
figure out how to build the /usr/cross/usr/lib/libc.a
In message: 4a15d288.3060...@telenix.org
Chuck Robey chu...@telenix.org writes:
: I got instructions from Warner about how to build my crosstools (the FreeBSD
: ones) and after a minor startup contretemps, things began to work better. My
: problem is that on doing the linking step,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 May 2009 14:12:00 -0700
Randy Bush ra...@psg.com mentioned:
i succeeded with putting 8-current snap on a pen and booting. but i can
not figure out how to tell it to use the pen drive for system image
loads.
What do you mean by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 May 2009 17:44:42 +0100
xorquew...@googlemail.com mentioned:
On 2009-05-21 16:10:18, Stanislav Sedov wrote:
You can also try using devel/cross-binutils to build cross-tools for
x86_64-freebsd. Random people reported they're working
i succeeded with putting 8-current snap on a pen and booting. but i can
not figure out how to tell it to use the pen drive for system image
loads.
What do you mean by system image loads? Does it load kernel succesfully
but cannot find root filesystem?
sorry. no. it wants the cd or ftp or
* Nate Eldredge (neldre...@math.ucsd.edu) wrote:
There may be a way to enable the conservative behavior; I know Linux
has an option to do this, but am not sure about FreeBSD.
I seem to remember a patch to disable overcommit. Here we go:
http://people.freebsd.org/~kib/overcommit/
--
There is no such thing as a graceful way to deal with running out of
memory. What is a program supposed to do? Even if it gracefully exits
it still fails to perform the function for which it was designed. If
such a program is used in a script then the script fails as well.
24 matches
Mail list logo
