On Mon, 19 Jul 1999 09:20:47 -0400 (EDT), "Richard B. Johnson"
<root@chaos.analogic.com> said:
> On Sat, 17 Jul 1999, Richard Johnson wrote:
>> > I don't like the idea of killing off tasks that request resources
>> > that are not presently available.
> On Sat, 17 Jul 1999, Rik van Riel wrote:
>> Have you thought about the problem at
>> all?
> Yep. And so did the guy who designed VAX/VMS. Now VMS is not Unix so
> there will be differences. Under VMS, a program was executed in the
> context of the current process.
Correct, so far...
> although Linux fork() and vfork() can usually work without
> allocation of any additional memory except stack.
No, the cost of the new page tables usually outweighs the stack.
> The idea is the notion of a 'swap' file as well as a 'page' file.
VMS only has one. Yes, it can do full-process swapping as well as
paging, but there are no separate files.
> When memory is low, the kernel will stop allocating new pages to a
> process. Instead, it will swap existing pages to disk on a per
> process basis.
No it won't. What VMS does is something I'd like Linux to be able to
do, but it is very different to what you describe. VMS is very, very
good at managing per-process resource limits and quotas. One such
limit is the "working set" limit --- the number of pages a process can
have mapped into its address space at once. This is akin to the rss
(resident set size) limit on many Unixen.
When a process exceeds its working set, its pages are unmapped using
standard page reclamation algorithms until it is back below the quota,
but the resulting freed pages are not necessarily discarded
immediately from memory: they remain in core, effectively in cache.
They can be paged back in again by a "soft" page fault.
The net result is that a process can exceed its working set limit on
an idle system with only minimal performance loss: it has to start
paging, but it just pages from cache. However, on a busier system,
processes exceeding their working set start to get paged to disk as
the system starts to reclaim old pages from cache.
> The result is that the kernel is never "out of memory". Instead,
> it's "out of swap". There is a difference. Tasks that don't need
> great gobs of memory continue. The memory hog can be seen and killed
> by its owner if necessary.
Not really. You can still run out of kernel memory on VMS: it usually
results in a kernel-mode bugcheck. However, that should only be
possible on a misconfigured system: the whole point of the quota
limits is that a well-configured system should be able to safeguard
enough memory, and reclaim used physical memory fast enough, to cope
with transient kernel mode requirements.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/