From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 4 Nov 2012 20:17:25 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20121104191725.GA1741@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> <20121104162757.GA525@polynum.com> Mime-Version: 1.0 In-Reply-To: <20121104162757.GA525@polynum.com> 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: d373533a-ead7-11e9-9d60-3106f5b1d025 On Sun, Nov 04, 2012 at 05:27:58PM +0100, tlaronde@polynum.com wrote: > > 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? > Just to add what would be "not existing": - user level - IPC since these memory blocks would be named "files". And as far as the G.R.A.S.S (geographical data processing) was involved, one could really need lots of "memory"; far more than what was available (end of eighties); and with increasing data size, problem is still here (well, with geographical data, one sorting is obvious: by location hence tiling; problem starts when one has to consider how to weave tile results, if the result of the whole may depend on non local (twice the size of the tile) interdependencies). -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C