Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Tue, 20 Jul 1999 13:13:31 +0100 (BST) | Subject | Re: OOM |
| |
Hi,
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/
| |