From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 4 Nov 2012 17:27:58 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20121104162757.GA525@polynum.com> References: <20121103163103.GA48522@intma.in> <5cff355142bfe83410dce1c3fc321f25@kw.quanstro.net> <20121103165100.GA63071@intma.in> <7cd2c11374f75d628a5bb5e1f1d0919e@kw.quanstro.net> <20121103171322.GA76929@intma.in> <20121103174555.GA96072@intma.in> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] Kernel panic when allocating a huge memory Topicbox-Message-UUID: d369fbfa-ead7-11e9-9d60-3106f5b1d025 On Sat, Nov 03, 2012 at 06:48:47PM +0000, Charles Forsyth wrote: > Wilkes has a nice discussion of paging algorithms as an application of > control theory > in "The Dynamics of Paging". > http://comjnl.oxfordjournals.org/content/16/1/4.short > > "It is notorious that the use of apparently innocuous scheduling and paging > algorithms can give rise to the type of unstable behaviour known as > thrashing." Just for the (historical) record, the original G.R.A.S.S. team, since the processing i.e. some kind of sorting of huge data typically raster may need a lot of memory, went as far as implementing a library in G.R.A.S.S. to do user level paging and swapping (indeed segmentation and use of disks but actually file system use to store segments of processing---the segment library). Has a "paging / swapping" filesystem (non persistent data, processes dependant timelife "memory" allocation, with storing/reloading to/from disk, and use of real memory when available) been attempted? -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C