SUMMARY 2: /usr/etc/chill - what the h*ll is it ? man page included.

From: Marcel Bernards (bernards@ECN.NL)
Date: Fri Mar 20 1992 - 12:13:21 CST


I got an overwhelming respons for posting the chill(8) man page.
I thought: "lets not waste the list by posting the whole man page", but
the many many mebers of the list think apparently different.
As a bonus , a part of the code heading, quite explicative:

---BEGIN---Cut-Here----8<----8<----8<----8<----8<----8<----8<----8<----8<----
From: smb@ulysses.att.com
Subject: Re: /usr/etc/chill - what the h*ll is it ?
Here's the comments from the head of the code:

  /*
  **
  ** NOTE: The original version (which allocated virtmem == maxmem
  ** and ran around cycle times) which was designed to flush out all
  ** other pages. But subsequent paging behavior indicates that not
  ** all pages were flushed. One failure mode I can see is as
  ** follows.
  **
  ** Let all of main memory be represented as ten page slots,
  ** numbered 0 to 9. Let the virtual memory pages in order be
  ** labeled a, b, ..., j. Let the suspected unflushed page be page
  ** 0. If the paging daemon hand were at page 1, and all but page 0
  ** were free, and the free pages were in reverse order, we would
  ** have the following picture after the first 9 accesses, none of
  ** which would cause a page fault:
  **
  ** + hand
  ** v
  ** 0 1 2 3 4 5 6 7 8 9
  ** X i h g f e d c b a
  **
  ** On the 10th access, we get
  **
  ** + hand
  ** v
  ** 0 1 2 3 4 5 6 7 8 9
  ** X j h g f e d c b a
  **
  ** We restart the cycle, and cause no faults on a..h.
  ** Access 9 yields
  **
  ** + hand
  ** v
  ** 0 1 2 3 4 5 6 7 8 9
  ** X j i g f e d c b a
  **
  ** and access 10 does not cause a page fault.
  **
  ** As you can see, page 0 is still, X, the unknown; it has not been
  ** forced out.
  **
  ** In view of this, the algorithm has been changed. The new
  ** algorithm is to allocate 2X maxmem, and cycle through it once.
  **
  ** version: @(#)chill.c 1.1 90/03/23 hacked from page1.c 1.6 87/06/20

It reads /dev/kmem to find maxmem.
---END-----Cut-Here----8<----8<----8<----8<----8<----8<----8<----8<----8<----

So, here it is:
---BEGIN---Cut-Here----8<----8<----8<----8<----8<----8<----8<----8<----8<----
.\" @(#)chill.8 1.1 90/10/29 SMI;
.TH CHILL 8 "06 April 1988"
.SH NAME
chill \- remove useful pages from the virtual memory cache
.SH SYNOPSIS
.B chill
[
.B \-c
.I cycles
]
[
.B \-f
.I factor
]
[
.B \-m
.I memsize
]
.SH DESCRIPTION
.IX "chill remove" "" "\fLchill\fP \(em remove useful pages from virtual memory cache" ""
.IX "remove" "useful pages from cache"
.IX memory "remove useful pages from cache"
.IX "cool" "cool off system"
.LP
.B chill
is a command designed to cool off the system by removing any
useful (to a process) pages from the virtual memory cache.
.B chill
does this by creating a large pool of private pages,
and then cycling through the pool, dirtying every page.
Currently, this forces
.BR chill 's
pages to be hot, which forces out all the other (non-locked)
pages in the system. Then when
.B chill
exits, all its private pages are put on the free list,
leaving no useful pages in memory.
.LP
With no options specified,
the size of the pool created by
.B chill
is twice the amount of pageable memory,
and it is cycled through just once.
This seems to give correct results with minimal overhead.
.LP
However, the size of the pool may be explicitly specified as
.IR memsize ,
or as
.I factor
times the amount of pageable memory.
.I memsize
overrides the
.I factor
specification.
The cycle count may be specified as
.IR cycles .
.SH OPTIONS
.TP
.BI "\-c " cycles
Set the cycle count to
.IR cycles .
The default is 1.
.TP
.BI "\-f " factor
Set the expansion factor to
.IR factor .
The default is 2.
.TP
.BI "\-m " memsize
Set the memory size to
.IR memsize .
The default is unspecified, which means that
.I factor
times the amount of pageable memory will be used.
.SH BUGS
.LP
.B chill
is dependent on implementation details
which are subject to change.
---END-----Cut-Here----8<----8<----8<----8<----8<----8<----8<----8<----8<----

Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN
(and SURFnet IC/ICP), Phone: (+31 /0)2246 4579 Fax: (+31 /0)2246 1864
E-Mail: Bernards@ECN.NL, SnailMail: P.O. Box 1, 1755 ZG Petten
SCREAMNet : AAAAAARGHH!HUH?? : Disclaimer: "The AntiChrist is the Computer !"



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:39 CDT