|
Home > Archive > Unix Programming > October 2007 > will system() waste memory?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
will system() waste memory?
|
|
| Bin Chen 2007-10-15, 7:31 am |
| Hi,
As I know, fork() will duplicate the parent's memory, to child, if the
child doesn't want to use the parent's memory, the memory is wasted,
system() is a thing like this.
Most call to system() is to run a brand new program but I want to know
if the parent run system() after allocated a large memory, will the
memory duplicated to the systemed program which is unnecessary?
If so, how can I do to avoid the wasted memory?
Thanks.
Bin
| |
| Ben Bacarisse 2007-10-15, 1:25 pm |
| Bin Chen <binary.chen@gmail.com> writes:
> As I know, fork() will duplicate the parent's memory, to child, if the
> child doesn't want to use the parent's memory, the memory is wasted,
> system() is a thing like this.
No. Whilst system might be implemented very badly, one can reasonably
assume that it will fork and immediately exec, thus replacing the
child's copy of the parent's process image.
> Most call to system() is to run a brand new program but I want to know
> if the parent run system() after allocated a large memory, will the
> memory duplicated to the systemed program which is unnecessary?
It may be duplicated briefly but, if it is, *nix systems are designed
to make this efficient.
--
Ben.
| |
| James Carlson 2007-10-15, 1:25 pm |
| Bin Chen <binary.chen@gmail.com> writes:
> As I know, fork() will duplicate the parent's memory, to child, if the
> child doesn't want to use the parent's memory, the memory is wasted,
Not exactly. fork() gives the child a replicated address space.
Whether things are actually copied or not depends on how the VM
subsystem is implemented, and what sorts of performance optimizations
the designer of the system you're using has made. Typically there's
only "some" copying going on.
> system() is a thing like this.
system() calls exec() -- that tears down all address space mappings in
the process.
> Most call to system() is to run a brand new program but I want to know
> if the parent run system() after allocated a large memory, will the
> memory duplicated to the systemed program which is unnecessary?
No. exec() causes the address space to be torn down and
reconstructed. See the exec(2) man page on your system for details.
--
James Carlson, Solaris Networking <james.d.carlson@sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
| |
| Daniel Rock 2007-10-15, 1:25 pm |
| Bin Chen <binary.chen@gmail.com> wrote:
> Most call to system() is to run a brand new program but I want to know
> if the parent run system() after allocated a large memory, will the
> memory duplicated to the systemed program which is unnecessary?
>
> If so, how can I do to avoid the wasted memory?
For this reason posix_spawn() has been introduced:
http://www.opengroup.org/onlinepubs...osix_spawn.html
See the discussion in the "Rationale" section.
You can assume system() uses the optimal implementation available on your
platform. system() might succeed in some cases where fork() + exec() would
fail.
--
Daniel
| |
| Rainer Weikusat 2007-10-15, 1:25 pm |
| "Daniel Rock" <v200742@deadcafe.de> writes:
> Bin Chen <binary.chen@gmail.com> wrote:
>
> For this reason posix_spawn() has been introduced:
This is not correct. The rationale states that 'posix_spawn' has been
introduced to supply a 'program execution primitive' which can be
implemented efficiently on hardware lacking a MMU:
The posix_spawn() function
[...]
been introduced to overcome the following perceived
difficulties with fork(): the fork() function is difficult or
impossible to implement without swapping or dynamic address
translation.
[...]
POSIX needs process creation and file execution primitives
that can be efficiently implemented without address
translation or other MMU services.
[...]
Also, although they may be an efficient replacement for many
fork()/ exec pairs, their goal is to provide useful process
creation primitives for systems that have difficulty with
fork(), not to provide drop-in replacements for fork()/ exec.
> You can assume system() uses the optimal implementation available on
> your platform.
Since system starts a shell which executes the supplied command, it is
certain that it is neither 'the optimal implementation' nor that it
uses anything except fork/exec for usual shells.
Additionally, it is equally certain that posix_spawn is less efficient
than fork/exec except if the environment of the newly created process
does not need to be modified before exec'ing a new program because it
needs to run an interpreter for a declarative micro-language to
determine and execute the intended changes, whereas code using
fork/exec would just implement them directly. It could be more
efficient if the OS in question supports a real vfork and the
programmer of the code its performance is compared with did not use
vfork despite no modifications to the environment of the newly created
process were necessary.
None if this matters anyhow, taking into account that UNIX(*) has been
used for timesharing on computers that were common in the mid-to-late
seventies with fork/exec, which apparently wasn't a problem.
| |
| Chris Friesen 2007-10-15, 1:25 pm |
| Bin Chen wrote:
> Most call to system() is to run a brand new program but I want to know
> if the parent run system() after allocated a large memory, will the
> memory duplicated to the systemed program which is unnecessary?
As others have said, it's not likely to be an issue. Most modern
systems use a copy-on-write mechanism, which means that in a fork/exec
scenario very little memory is actually duplicated.
One case where there could potentially be a problem is if strict memory
accounting is enabled on linux with very tight accounting settings. If
there is not enough memory left in the system for two copies of the
original program, the fork() call may fail.
Generally the memory accounting settings are loose enough (and
individual apps are small enough) that this isn't a common problem.
Chris
| |
| Daniel Rock 2007-10-15, 1:25 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Daniel Rock" <v200742@deadcafe.de> writes:
>
> Since system starts a shell which executes the supplied command, it is
> certain that it is neither 'the optimal implementation' nor that it
> uses anything except fork/exec for usual shells.
There is no "unusual shell" in the sense of system().
Why shouldn't it use something else if that is available? Solaris does use
posix_spawn() for system():
http://cvs.opensolaris.org/source/x.../stdio/system.c
http://developers.sun.com/solaris/a...subprocess.html
> Additionally, it is equally certain that posix_spawn is less efficient
> than fork/exec except if the environment of the newly created process
> does not need to be modified before exec'ing a new program because it
> needs to run an interpreter for a declarative micro-language to
> determine and execute the intended changes, whereas code using
> fork/exec would just implement them directly. It could be more
> efficient if the OS in question supports a real vfork and the
> programmer of the code its performance is compared with did not use
> vfork despite no modifications to the environment of the newly created
> process were necessary.
posix_spawn() is likely to be more efficient than fork()/exec() in most
of the cases when implementing system(). Preparing the address space
of the originating process and reserving the virtual memory needed for
duplicating the address space are expensive tasks.
--
Daniel
| |
| Bin Chen 2007-10-16, 1:28 am |
| On 10 15 , 11 43 , Chris Friesen <cbf...@mail.usask.ca> wrote:
> Bin Chen wrote:
>
> As others have said, it's not likely to be an issue. Most modern
> systems use a copy-on-write mechanism, which means that in a fork/exec
> scenario very little memory is actually duplicated.
>
No, I think copy-on-write still consumpt something that is unnessary
such as page frame structure. But if first fork than exec, it still
will be a performance penalty, right? We do a allocate mm in child and
exec() will free than, why not just provide a single function just NOT
copy the mm?
I think it is the point.
> One case where there could potentially be a problem is if strict memory
> accounting is enabled on linux with very tight accounting settings. If
> there is not enough memory left in the system for two copies of the
> original program, the fork() call may fail.
>
> Generally the memory accounting settings are loose enough (and
> individual apps are small enough) that this isn't a common problem.
>
> Chris
| |
| Bin Chen 2007-10-16, 1:28 am |
| On 10 15 , 11 43 , Chris Friesen <cbf...@mail.usask.ca> wrote:
> Bin Chen wrote:
>
> As others have said, it's not likely to be an issue. Most modern
> systems use a copy-on-write mechanism, which means that in a fork/exec
> scenario very little memory is actually duplicated.
>
No, I think copy-on-write still consumpt something that is unnessary
such as page frame structure. But if first fork than exec, it still
will be a performance penalty, right? We do a allocate mm in child and
exec() will free than, why not just provide a single function just NOT
copy the mm?
I think it is the point.
> One case where there could potentially be a problem is if strict memory
> accounting is enabled on linux with very tight accounting settings. If
> there is not enough memory left in the system for two copies of the
> original program, the fork() call may fail.
>
> Generally the memory accounting settings are loose enough (and
> individual apps are small enough) that this isn't a common problem.
>
> Chris
| |
| David Schwartz 2007-10-16, 1:28 am |
| On Oct 15, 5:00 am, Bin Chen <binary.c...@gmail.com> wrote:
> As I know, fork() will duplicate the parent's memory, to child, if the
> child doesn't want to use the parent's memory, the memory is wasted,
> system() is a thing like this.
>
> Most call to system() is to run a brand new program but I want to know
> if the parent run system() after allocated a large memory, will the
> memory duplicated to the systemed program which is unnecessary?
>
> If so, how can I do to avoid the wasted memory?
Why do you care? Virtual memory is not a scarce resource.
DS
| |
| Chris Friesen 2007-10-16, 1:28 am |
| Bin Chen wrote:
> No, I think copy-on-write still consumpt something that is unnessary
> such as page frame structure. But if first fork than exec, it still
> will be a performance penalty, right? We do a allocate mm in child and
> exec() will free than, why not just provide a single function just NOT
> copy the mm?
That's why vfork() was created. It does exactly that--the child runs
using the parent's page tables, and is very limited in what it can do.
However, there are issues with using vfork() properly. It's possible
that on some implementations system() is implemented using vfork/exec
internally to libc.
On the other hand, anyone that cares about performance shouldn't be
using system() to begin with...they should be using long-running
processes communicating with messages or shared memory.
Chris
| |
| Chris Friesen 2007-10-16, 1:28 am |
| David Schwartz wrote:
> On Oct 15, 5:00 am, Bin Chen <binary.c...@gmail.com> wrote:
[vbcol=seagreen]
> Why do you care? Virtual memory is not a scarce resource.
It is if strict memory accounting is enabled and the process being
forked has allocated more than half of physical memory. However, I
think the OP was more concerned about performance.
Chris
| |
| Rainer Weikusat 2007-10-16, 7:30 am |
| "Daniel Rock" <v200742@deadcafe.de> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> There is no "unusual shell" in the sense of system().
There are quite a few more-or-less bourne-shell compatible shells
available and most of them presumably use fork/exec to spawn the
command to be executed because the code is sufficiently old.
> Why shouldn't it use something else if that is available? Solaris does use
> posix_spawn() for system():
>
> http://cvs.opensolaris.org/source/x.../stdio/system.c
>
> http://developers.sun.com/solaris/a...subprocess.html
Executive summary: fork performance on Solaris sucks and it doesn't
implement lazy swap allocation like 'most other systems'.
Insofar you intended to write 'if you are developing applications
whose address space is going to be extraordinarily large (>> 1G),
which are specifcally targetted at Solaris and which need to execute
external commands during their normal cause of operation, then
posix_spawn can be used to work around technical deficiencies of the
operating environment which may cause code working fine everywhere
else to fail', that would have been correct. Adding the tactful
assumption that it is ok to use vfork, ie to suspend the process
trying to execute an external command until this command has
started. Taking into account that vfork cannot be used reliably in
multi-threaded applications on Solaris due to bugs in the
implementation of the dynamic linker. Of course, this code won't
even be portable to Solaris 9, then and it will actually perform worse
on systems using glibc and not work at all on any of the BSDs, on
HP-UX up to 11.22, on AIX up to 5L etc.
A better suggestion would be to ignore specific problems of Solaris,
insofar possible, and count on Sun fixing them sooner or later,
because of this.
>
> posix_spawn() is likely to be more efficient than fork()/exec() in most
> of the cases when implementing system().
This doesn't really matter, because the execution of /bin/sh, followed
by parsing a command and executing that via fork/exec will certainly
be sufficient for kill any theoretical advantage insofar none of the
original failure conditions do apply. Not to mention that it is
entirely conceivable that posix_spawn is actually implemented using
fork/exec.
| |
| Rainer Weikusat 2007-10-16, 7:30 am |
| Bin Chen <binary.chen@gmail.com> writes:
> On 10 15 , 11 43 , Chris Friesen <cbf...@mail.usask.ca> wrote:
> No, I think copy-on-write still consumpt something that is unnessary
> such as page frame structure.
It is theoretically possible to share that as well. That nobody has
actually implemented this (in Linux) so far should be a strong hint
that any eventual benefit es negligible.
> But if first fork than exec, it still will be a performance penalty,
> right? We do a allocate mm in child and exec() will free than, why
> not just provide a single function just NOT copy the mm?
Programs running external commands usually intend to use their
functionality to accomplish something particular. This means 'certain
arrangements' are necessary to be able to use the external command,
like setting up file descriptors appropriately. For a program with
'simple' error handling (ie failure is always terminal), and example
could look like this:
static int start_send_cmd(void)
{
int fds[2], rc;
rc = pipe(fds);
rc != -1 || sys_die(__func__, "pipe", errno);
rc = fork();
switch (rc) {
case 0:
dup2(*fds, STDIN_FILENO);
close(*fds);
close(fds[1]);
execv(*eli_sa_send, (void *)eli_sa_send);
sys_die(__func__, "execv", errno);
case -1:
sys_die(__func__, "fork", errno);
}
close(*fds);
return fds[1];
}
[code (c) my employer and cited for educational purposes]
Accomplishing the same using a 'unified' spawn-primitive is
signifcantly more complicated.
| |
| Giorgos Keramidas 2007-10-16, 7:30 am |
| On 15 Oct 2007 21:11:51 -0700, Bin Chen <binary.chen@gmail.com> wrote:
> On 10 15 , 11 43 , Chris Friesen <cbf...@mail.usask.ca> wrote:
>
> No, I think copy-on-write still consumpt something that is unnessary
> such as page frame structure. But if first fork than exec, it still
> will be a performance penalty, right? We do a allocate mm in child and
> exec() will free than, why not just provide a single function just NOT
> copy the mm?
FWIW, this is exactly what vfork() does :-)
| |
| Daniel Rock 2007-10-16, 1:28 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Daniel Rock" <v200742@deadcafe.de> writes:
>
> There are quite a few more-or-less bourne-shell compatible shells
> available and most of them presumably use fork/exec to spawn the
> command to be executed because the code is sufficiently old.
What does this have to do with system()?
> Executive summary: fork performance on Solaris sucks and it doesn't
> implement lazy swap allocation like 'most other systems'.
I don't want any system which does memory overcommit. I want deterministic
system behaviour.
> A better suggestion would be to ignore specific problems of Solaris,
> insofar possible, and count on Sun fixing them sooner or later,
> because of this.
Which problems?
> This doesn't really matter, because the execution of /bin/sh, followed
> by parsing a command and executing that via fork/exec will certainly
> be sufficient for kill any theoretical advantage
And what makes this different from system()? (Hint: read the subject line)
--
Daniel
| |
| Rainer Weikusat 2007-10-16, 1:28 pm |
| "Daniel Rock" <v200742@deadcafe.de> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> What does this have to do with system()?
This is a question which can be easily answered by using either the
standard text or the available system documentation.
>
> I don't want any system which does memory overcommit. I want
> deterministic system behaviour.
In the given context, this means that you want a system where 'large
processes' cannot sensibly use fork/exec to execute external
commands, despite reserving enough swap space to eventually store
all of the contents of the inherited address space is completely
unnecessary for this particular case.
[...]
>
> Which problems?
The mentioned self-deadlock of the dynamic linker, for instance. Or
the (reportedly) bad fork performance.
>
> And what makes this different from system()?
Why would it be different from system?
| |
| Daniel Rock 2007-10-16, 1:28 pm |
| Lines: 29
NNTP-Posting-Date: 16 Oct 2007 19:14:28 CEST
NNTP-Posting-Host: f716838d.newsspool4.arcor-online.net
X-Trace: DXC=6Z>YAR7F6a2nBOkdL^Lo7>4IUK<Cl32<14Fo<]lROoR1^YC2XCjHcb93>[[J;o@:79a>N4_IKiX7;K]c4f0Cm9h7l>3IR0;IlZ37bam[TH3jo<n4HjUacX8F9
X-Complaints-To: usenet-abuse@arcor.de
Bytes: 2126
Xref: number1.nntp.dca.giganews.com comp.unix.programmer:181414
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> This is a question which can be easily answered by using either the
> standard text or the available system documentation.
Like I said.
>
> In the given context, this means that you want a system where 'large
> processes' cannot sensibly use fork/exec to execute external
> commands, despite reserving enough swap space to eventually store
> all of the contents of the inherited address space is completely
> unnecessary for this particular case.
But the kernel doesn't know. There are more cases fork() can be used than
calling exec(). Backing store (disks) is cheap nowadays.
>
> Why would it be different from system?
That's what I'm asking you.
--
Daniel
| |
| Rainer Weikusat 2007-10-17, 7:32 am |
| "Daniel Rock" <v200742@deadcafe.de> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> But the kernel doesn't know. There are more cases fork() can be used than
> calling exec(). Backing store (disks) is cheap nowadays.
Actually, the kernel can make either of two assumptions:
a) optimistic assumption: Backing store will be available when
(and if) it is actually needed.
b) pessimistic assumption: Backing store for the complete
address space will be needed and won't be available unless
reserved beforehand.
Both assumptions can cause something to fail which would otherwise
have succeeded. The qualitative difference can be expressed by the
question: Should the system rather try and eventually fail or rather
refuse to avoid failing?
And this is a policy question with no 'right' answer at this
level. A sensible default would (IMHO) be to usually provide 'best
effort' service and to allow for a policy override in situation where
failure cannot be tolerated, assuming a general-purpose timesharing/
internetworking system.
>
> That's what I'm asking you.
But since the description was intended to describe system, the
question appears to be somehwat pointless.
| |
| Daniel Rock 2007-10-17, 7:32 am |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> a) optimistic assumption: Backing store will be available when
> (and if) it is actually needed.
>
> b) pessimistic assumption: Backing store for the complete
> address space will be needed and won't be available unless
> reserved beforehand.
>
> Both assumptions can cause something to fail which would otherwise
> have succeeded. The qualitative difference can be expressed by the
> question: Should the system rather try and eventually fail or rather
> refuse to avoid failing?
No the system doesn't fail in the pessimistic case. A return value of
NULL to malloc() is not a failure to the system. I prefer the deterministic
approach. Configuring large swap doesn't cost much nowadays.
> And this is a policy question with no 'right' answer at this
> level. A sensible default would (IMHO) be to usually provide 'best
> effort' service and to allow for a policy override in situation where
> failure cannot be tolerated, assuming a general-purpose timesharing/
> internetworking system.
Don't let the computer try to be clever. He will be wrong most of the time.
--
Daniel
| |
| Rainer Weikusat 2007-10-17, 1:28 pm |
| "Daniel Rock" <v200742@deadcafe.de> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> No the system doesn't fail in the pessimistic case.
> A return value of NULL to malloc() is not a failure to the system.
The system call in question happened to be fork, not some kind of
'address space extension primitive'. And a process which cannot
accomplish some task because of lack of ressources and a process which
cannot accomplish some task because the system refused to create in in
the first place have both failed to accomplish 'some task'.
NB: "An den Sophisten kann man doch bloss intellektuelle Turnuebungen
vollziehen" (Sophists are useless except as devices for intellectual
exercise).
[...]
>
> Don't let the computer try to be clever. He will be wrong most of
> the time.
Correct. So don't let the computer try to be clever wrt how much VM it
may need in future. It will be wrong most of the time and
gratuitously refuse to serve its users. But this actually cuts both
ways. The 'right' strategy is the one which would not have led to the
failure that happened because the other strategy had been chosen.
| |
| Daniel Rock 2007-10-17, 1:28 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> NB: "An den Sophisten kann man doch bloss intellektuelle Turnuebungen
> vollziehen" (Sophists are useless except as devices for intellectual
> exercise).
>
Translation: blah blah
>
> Correct. So don't let the computer try to be clever wrt how much VM it
> may need in future. It will be wrong most of the time and
> gratuitously refuse to serve its users.
.... Instead it will kill poor unrelated victims which tried to access a
page they malloc'd long before at the wrong time.
Yes, you are absolutely right. Don't let the OS decide. Let the adminstrator
configure the system with enough swap.
--
Daniel
| |
| Rainer Weikusat 2007-10-17, 1:28 pm |
| "Daniel Rock" <v200742@deadcafe.de> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> Translation: blah blah
The translation of the text you happened to quote would be 'I strongly
suspect that you try to score a point by suitable reinterpretations of
parts of the text I had actually written. This implies that you are not
actually interested in discussing a technical phenomenon and that
taking you seriously is, except insofar pretending to would be
entertaining, somewhat of a waste of time.
[...]
>
> ... Instead it will kill poor unrelated victims which tried to access a
> page they malloc'd long before at the wrong time.
>
> Yes, you are absolutely right.
I am absolutely right(*): There are (for the fork case I was writing
about), two possible strategies and each of them may be the wrong
choice.
(*) At least, that would be my understanding of the issue and
you haven't added anything of any substance to that.
| |
| Daniel Rock 2007-10-17, 1:28 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Daniel Rock" <v200742@deadcafe.de> writes:
> The translation of the text you happened to quote would be 'I strongly
> suspect that you try to score a point by suitable reinterpretations of
> parts of the text I had actually written. This implies that you are not
> actually interested in discussing a technical phenomenon and that
> taking you seriously is, except insofar pretending to would be
> entertaining, somewhat of a waste of time.
Blah Blah
> There are (for the fork case I was writing
> about), two possible strategies and each of them may be the wrong
> choice.
No, giving the system enough swap is never the wrong choice. But killing
unrelated processes randomly is never the right choice.
--
Daniel
| |
| Giorgos Keramidas 2007-10-19, 1:32 pm |
| On Wed, 17 Oct 2007 15:06:46 +0000 (UTC), "Daniel Rock" <v200742@deadcafe.de> wrote:
>Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> No, giving the system enough swap is never the wrong choice. But killing
> unrelated processes randomly is never the right choice.
I think what Rainer means is that it may be 'tricky' at best to define
'enough' in the phrase 'enough swap'.
He doesn't disagree with your preference for non-overcommitting memory;
he is just stating that sometimes, despite all the efforts put into
properly planning ahead, it is still possible to find one's self in a
state where swap is not enough. In those cases, fork() will fail to
create a new process. You are entitled to an opinion that this is not a
*system* failure, but a failure in a single process attempting to
fork(). This is still _some_ sort of failure though -- much more
predictable, reproducible and traceable than a random OOM killer reaping
innocent processes, mind you -- but _some_ sort of failure, nonetheless 
We have diverged very far from the original "does system() waste memory"
question. Can we agree that depending on a design decision (to
overcommit or not), there may be failure modes regardless of the initial
design choise? Flaming each other to ashes doesn't really sound like a
constructive thing to do in c.u.p
- Giorgos
| |
| Rainer Weikusat 2007-10-21, 7:22 pm |
| Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> On Wed, 17 Oct 2007 15:06:46 +0000 (UTC), "Daniel Rock" <v200742@deadcafe.de> wrote:
>
> I think what Rainer means is that it may be 'tricky' at best to define
> 'enough' in the phrase 'enough swap'.
>
> He doesn't disagree with your preference for non-overcommitting
> memory;
I wasn't writing about general memory overcommittment at all. Neither
did I write about 'system failures'. Both were just issues Mr Rock
introduced into the 'discussion'. For the sake of completeness, I
repeat the statement I made, just to show the difference again.
Assuming a sufficiently large process (larger than the amount of swap
space the system can presently provide) calls fork, there are two
possible assumptions the kernel can make about its future memory usage:
a) The process will not need all of its inherited address
space and what it actually will need will be available by the
time it is needed. This is very likely if the new process will
do an exec soon. So, let the fork succeed and hope for the
best. If this assumption is wrong, the process will fail
to complete whatever its task was because it will run out of
memory while trying to.
b) The process will need all of its inherited address space
and sufficient virtual memory will not be available in time,
hence, it must be reserved beforehand. Consequently, the fork
will fail and the process that should have been created will
fail to accomplish its task because of this.
Assuming the failure in a) is worse than the failure in b), there is
no 'correct' descision the kernel can make: Not trying ascertains a
'more harmless' failure. While trying could succeed, it could equally
well lead to a 'more dangerous failure'.
And 'failure' in this context is just supposed to mean 'the program
could not accomplish what it should have accomplished if the fork had
succeeded and sufficient memory to complete this task had been
available'.
| |
| Daniel Rock 2007-10-21, 7:22 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Assuming the failure in a) is worse than the failure in b), there is
> no 'correct' descision the kernel can make:
The kernel shouldn't decide or throw dices. It's the administrator's
responsibilty to give the system enough swap space.
--
Daniel
| |
| Golden California Girls 2007-10-22, 1:35 am |
| Daniel Rock wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> The kernel shouldn't decide or throw dices. It's the administrator's
> responsibilty to give the system enough swap space.
So the admin is supposed to look in his crystal ball and know this user who
doesn't even have an account on the machine yet, is going to run this big
process a couple of years later and allocate more space even though the bosses
above refused the request for more disk space because it isn't needed today.
| |
| Daniel Rock 2007-10-22, 1:27 pm |
| Golden California Girls <GldnCAGrls@aol.com.mil> wrote:
> Daniel Rock wrote:
>
> So the admin is supposed to look in his crystal ball and know this user who
> doesn't even have an account on the machine yet, is going to run this big
> process a couple of years later and allocate more space even though the bosses
> above refused the request for more disk space because it isn't needed today.
No. Why should an admin configure for something which isn't there yet?
It is very unlikely the machine won't have an admin in a couple of years
later.
Adding swap isn't a one way task. It can be added anytime.
--
Daniel
|
|
|
|
|