Memory size?

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:

|> There are perfectly good reasons for this strategy and, on platforms
|> where they have a choice, users prefer the unsafe mode.

They prefer it so much that IBM was forced to abandon it as the default
mode on the AIX.

Do you know for a fact that the change was due to customer complaints?

There are some users, particularly those doing mathematical calculations
in research centers, for whom it might not be a real hinderness -- in
fact, it might even make like a very little bit simpler.

I selected lazy swap allocation on my old Digital Unix box for reasons
that have exactly zilch to do with mathematical calculations and
everything to do with the fact that far too many programs allocate plenty
of memory they never use and eager swap allocation severely reduced the
usability of my system.

But there are
a lot of users whose programs have to work correctly, and back out
correctly if the resources aren't there to support it. None of my
customers would ever knowingly have accepted such behavior.

Only someone who has experimented with both strategies can make an
*informed* choice.

Dan

 

[Michael Wojcik]

(e-mail address removed) (Dan Pop) writes:
|> There are perfectly good reasons for this strategy and, on platforms
|> where they have a choice, users prefer the unsafe mode.

They prefer it so much that IBM was forced to abandon it as the default
mode on the AIX.

Oh, really? When was that? The AIX 5.1L documentation still says:

The operating system uses the PSALLOC environment variable to
determine the mechanism used for memory and paging space allocation.
If the PSALLOC environment variable is not set, is set to null, or is
set to any value other than early, the system uses the default late
allocation algorithm.[1]

Perhaps you're thinking of the newer tree-style allocator, which is now
the default, versus the "3.1" buddy-system allocator.

1. http://publibn.boulder.ibm.com/doc_...ixbman/admnconc/pag_space_under.htm#HDRA8F021

 

[James Kanze]

(e-mail address removed) (Richard Bos) writes:


|> > (e-mail address removed) (Dan Pop) writes:

|> > |> There are perfectly good reasons for this strategy and, on
|> > |> platforms where they have a choice, users prefer the unsafe
|> > |> mode.

|> > They prefer it so much that IBM was forced to abandon it as the
|> > default mode on the AIX.

|> > There are some users, particularly those doing mathematical
|> > calculations in research centers, for whom it might not be a real
|> > hinderness -- in fact, it might even make like a very little bit
|> > simpler. But there are a lot of users whose programs have to work
|> > correctly, and back out correctly if the resources aren't there to
|> > support it. None of my customers would ever knowingly have
|> > accepted such behavior.

|> Neither would I, and nor would my users. Telling them that I'm very
|> sorry, but their last hour's entered text is completely lost because
|> their system doesn't have a big enough disk is simply not
|> acceptable.

You don't get to tell them. The way it worked with the AIX was that
your program core dumped. My users like that even less.

 

[Richard Bos]

(e-mail address removed) (Richard Bos) writes:

|> Neither would I, and nor would my users. Telling them that I'm very
|> sorry, but their last hour's entered text is completely lost because
|> their system doesn't have a big enough disk is simply not
|> acceptable.

You don't get to tell them. The way it worked with the AIX was that
your program core dumped. My users like that even less.

My users know where to find me; I'm an in-house programmer. Believe me,
I'd have to tell them how, why, and what I think I'm going to do about
it - _and_ who is about to re-enter all that data.
Although, to be fair, usually I would be able to put the blame on
Windows. All too often, that would be justified, too :-/

Richard

 

[Dan Pop]

(e-mail address removed) (Richard Bos) writes:

|> Neither would I, and nor would my users. Telling them that I'm very
|> sorry, but their last hour's entered text is completely lost because
|> their system doesn't have a big enough disk is simply not
|> acceptable.

You don't get to tell them. The way it worked with the AIX was that
your program core dumped. My users like that even less.

IIRC, AIX actually sent a signal to the program, when this happened.
If you didn't catch it and take whatever measures were appropriate,
you have only yourself to blame.

The typical behaviour behaviour of other OSs using lazy swap allocation
was to kill *other* processes, in order to gain memory for the one
needing it. So, when I started losing xterms, I knew that I have to
terminate my netscape session ASAP ;-)

Dan

 

[Michael Wojcik]

IIRC, AIX actually sent a signal to the program, when this happened.
If you didn't catch it and take whatever measures were appropriate,
you have only yourself to blame.

Correct. When paging space runs low, AIX sends SIGDANGER to every
user process. A few seconds later, if memory consumption has not
been reduced, it begins to send SIGKILL to those processes which *did
not catch SIGDANGER* and are consuming the most virtual memory. It
only begins killing processes which received SIGDANGER and caught it
if the low-memory condition continues.

Processes can also poll for low-paging-space conditions using the
psdanger system call.

In other words, there's ample opportunity for every program to detect
the low-memory condition and take appropriate action, like
checkpointing its state and perhaps releasing some memory. The
latter is more feasible for some programs than for others, of course,
but most AIX programs can trivially return some memory to the system
using the mallopt function with the M_DISCLAIM command, which tells
the malloc subsystem to return freed pages to the OS (via the
disclaim system call). This is completely transparent to the
application - they remain mapped in the app's address space, and will
be reallocated from the VMM pool if and when they're needed to
satisfy future malloc requests.

This is all in the AIX documentation. Much of it is right in the
malloc man page.

Frankly, I'd be pretty suspicious of any application that runs for an
hour without checkpointing, as in Richard's example. Low virtual
memory is hardly the only condition which might interrupt it.

--
Michael Wojcik (e-mail address removed)

I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_

 

[Richard Bos]

Correct. When paging space runs low, AIX sends SIGDANGER to every
user process.

That's not an ISO C signal, so an ISO C program cannot be expected to
catch it.

Processes can also poll for low-paging-space conditions using the
psdanger system call.

Which is not an ISO C function.

In other words, there's ample opportunity for every program to detect
the low-memory condition and take appropriate action,

Provided they are not ISO C programs.

In other words, programs portable nowhere else but to AIX have a
fighting chance. Correct, portable, ISO C programs are the first to be
dumped unceremoniously in the dunghill. Is this supposed to make me feel
happier about it?

Frankly, I'd be pretty suspicious of any application that runs for an
hour without checkpointing, as in Richard's example. Low virtual
memory is hardly the only condition which might interrupt it.

So would I, but
- we are not all in a position where we can avoid using programs like M$
Word, whose checkpoint files I have never found very useful (unlike,
say, those written by WordPerfect);
- losing only ten minutes' work is also irritating, if it happens often
enough. For some people, "often enough" is "twice", and sometimes with
good reason.

Richard

 

[Dan Pop]

That's not an ISO C signal, so an ISO C program cannot be expected to
catch it.

Are you gaining your living by writing ISO C programs? Are your
customers happy when you tell them that half of their specification cannot
be implemented in ISO C and that the program's interactive I/O sucks
because this is the best one can do in ISO C?

Dan

 

[SM Ryan]

# Which is not an ISO C function.
#
# > In other words, there's ample opportunity for every program to detect
# > the low-memory condition and take appropriate action,
#
# Provided they are not ISO C programs.
#
# In other words, programs portable nowhere else but to AIX have a
# fighting chance. Correct, portable, ISO C programs are the first to be
# dumped unceremoniously in the dunghill. Is this supposed to make me feel
# happier about it?

What a whiner. Until we finish the Cray-INF with unlimited virtual memory,
how best to deal with running out of resources? Unceremoniously kill
everyone because that way we get uniform behaviour? Or give programs
an opportunity for a graceful exit, if they choose to exploit it?

 

[Mark McIntyre]

# Which is not an ISO C function.
#
# > In other words, there's ample opportunity for every program to detect
# > the low-memory condition and take appropriate action,
#
# Provided they are not ISO C programs.
#
# In other words, programs portable nowhere else but to AIX have a
# fighting chance. Correct, portable, ISO C programs are the first to be
# dumped unceremoniously in the dunghill. Is this supposed to make me feel
# happier about it?

What a whiner.

Not.

Until we finish the Cray-INF with unlimited virtual memory,
how best to deal with running out of resources?

In platform specific ways, which are utterly offtopic here.

Unceremoniously kill
everyone because that way we get uniform behaviour? Or give programs
an opportunity for a graceful exit, if they choose to exploit it?

Ive seen both. And many other possibilities.

 

[Richard Bos]

SM Ryan

# Which is not an ISO C function.
#
# > In other words, there's ample opportunity for every program to detect
# > the low-memory condition and take appropriate action,
#
# Provided they are not ISO C programs.
#
# In other words, programs portable nowhere else but to AIX have a
# fighting chance. Correct, portable, ISO C programs are the first to be
# dumped unceremoniously in the dunghill. Is this supposed to make me feel
# happier about it?

What a whiner. Until we finish the Cray-INF with unlimited virtual memory,
how best to deal with running out of resources? Unceremoniously kill
everyone because that way we get uniform behaviour? Or give programs
an opportunity for a graceful exit, if they choose to exploit it?

The latter. And therefore, when you can't give a program the memory it
asks for, you have it _return a null pointer_, not pretend to be in
happy-happy land and _then_ unceremoniously kill it or random other
programs just because you can.

Richard