Re: [Lit.] Buffer overruns
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 02/04/05
- Next message: David Wagner: "Re: [Lit.] Buffer overruns"
- Previous message: infobahn: "Re: Thou shalt have no other gods before the ANSI C standard"
- In reply to: Chris Adams: "Re: [Lit.] Buffer overruns"
- Next in thread: Steve O'Hara-Smith: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 03 Feb 2005 22:12:31 -0700
cmadams@hiwaay.net (Chris Adams) writes:
> OSF/1^UDEC^WDigital Unix^WCompaq^WHP Tru64 Unix has overcommit in the
> form of "lazy" swap allocation. The kernel only allocates swap when it
> is needed, and if it can't, it starts killing processes (including
> kernel processes).
part of the issue with page backing store allocation policy is whether
or not you have dups or not ... especially with large real memories. I
had done dynamic adaptive dup/no-dup allocation algorithms in the late
'70s. with a dup algorithm, once a disk location is allocated on
initial page out ... then it remains allocated even on subsequent page
in operations (i.e. there are two copies, one in memory and one on
disk). if the page then is selected for replacement ... and it hasn't
been modified during the most recently stay in storage ... then the
copy on disk could be considered still valid ... and you avoid the
page-out operation. in the no-dup scenario ... the backing storage
location is released as soon as a page is read into memory.
"lazy" swap tends to be sort of like no-dup ... but only for the
initial allocation. you can still overcommit a no-dup policy ... but
it gives a little bit better breathing room. i ran into a number of
unixes during the 90s that had "lazy" swap but a dup policty (once
allocated) and would bring themselves down. System initially booted,
some number of demons and other processors initialized and when to
sleep. application came along and started running ... forcing all the
pages for these startup routines to disk. the application is running
fine ... but "lazy" swap hasn't yet allocated any space. some of the
demons start to wake up and are being brought into memory ... which
starts forcing application pages out. The system hangs at this point
since there hasn't been enuf page space on disk allocated for a "dup"
policy ... but there would have been sufficient space if system was
able to dynamically switch to a "no-dup" policy. One could claim that
while dup policy was in-force, that a system could be quite a bit more
liberal in its allocation strategy ... but at a point where it was
forced from dup to no-dup policy ... it would start becoming quite a
bit more conservative.
In the "dup" policy ... you eventually need to have enuf disk space
for all pages that might exist. In a "no-dup" policy, the total number
of pages supportable is the combination of the allocated disk space
plus the pageable real memory. A "dup" policy might advise allocated
twice as much disk space for pages as there is real memory. A "no-dup"
policy might get along fine with the same amount of disk space as
there is real memory.
for some thread drift ... some amount about page replacement
algorithms that i had originated as undergraduate in the '60s
http://www.garlic.com/~lynn/subtopic.html#wsclock
some number of past threads on dup/no-dup allocation policie
http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002f.html#26 Blade architectures
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: David Wagner: "Re: [Lit.] Buffer overruns"
- Previous message: infobahn: "Re: Thou shalt have no other gods before the ANSI C standard"
- In reply to: Chris Adams: "Re: [Lit.] Buffer overruns"
- Next in thread: Steve O'Hara-Smith: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
