Date: Thu, 15 Jul 1999 11:09:01 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Noriyuki Soda <soda@sra.co.jp> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <199907151809.LAA11823@apollo.backplane.com> References: <378D67B3.3E2A703C@newsguy.com> <Pine.GSO.3.95.990715082122.11860B-100000@jericho> <199907151738.CAA10933@srapc342.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
:Both Dillon and Sobral mistakenly claimed that "Solaris overcommits",
:this fact seems to be somewhat suggestive.
:
:And also, the followings are allocated memory and reserved memory
:in my environment. (This table also includes Eduardo's example)
:
: SunOS allocated reserved total total/allocated
: ----- --------- -------- -------- ------------
: 4.1.4 4268k 1248k 5516k 1.2924
: 4.1.2 7732k 1492k 9224k 1.193
: 4.1.4 8848k 3080k 11928k 1.3481
: 4.1.4 13532k 6772k 20304k 1.5004
: 5.5.1 15312k 5092k 20404k 1.3325
: 4.1.3 16112k 6512k 22624k 1.4042
: 4.1.2 26356k 1620k 27976k 1.0615
: 4.1.4 26560k 3756k 30316k 1.1414
: 5.5 26076k 11348k 37424k 1.4352
: 4.1.4 32984k 5556k 38540k 1.1684
: 5.6 32448k 7072k 39520k 1.2179
: 4.1.4 38056k 3692k 41748k 1.097
: 4.1.4 49064k 7672k 56736k 1.1564
: 4.1.4 67012k 7800k 74812k 1.1164
: 4.1.4 99348k 16956k 116304k 1.1707
: 4.1.4 118288k 11780k 130068k 1.0996
: 5.6 231968k 18880k 250848k 1.0814
: 5.7 307240k 19464k 326704k 1.0634
:
: (sorted by total amount of used swap)
:
:In those examples, non-overcommiting system requires 1.06x ... 1.50x
:...
:soda
Umm... how are you getting the reserved numbers? Are you
sure that isn't simply cached swap blocks? I.E. when something
gets swapped out and then is swapped back in and dirtied,
Solaris may be holding the swap block assignment rather
then letting it go. FreeBSD-stable does the same thing.
FreeBSD-current does not -- it lets it go in order to be
able to reallocate it later as part of a contiguous swath
for performance reasons.
These 'extra' swap blocks are effectively reserved but not
actually allocated. They can be reassigned. The numbers
above are very similar to what you would see in a
redirtying-cache swap block situation on a FreeBSD-stable
system.
If I add up all the unshared writeable segments on my
home box - that is, all segments for which one would
potentially have to reserve swap space - I get a total
of around 382MB. The machine is currently eating around
100MB of ram and 5MB of swap, or around a 3.5:1 ratio
in this case. A non-overcommit model would have to
reserve swap space for 382MB - 100MB = 282MB verses the
5MB of swap the machine actually allocates.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907151809.LAA11823>