derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (02/06/90)
> When the server starts, it takes about 20 Mb on the disk !!!
This is neither a bug nor a feature of the Mspice server, but
is a side-effect of Aegis being trashed in favor of JLRU.
Under "real Aegis", if a large amount of virtual memory was
allocated, it did not take up disk space until some item in
a particular page was touched. Then, that page was mapped
to disk. The advantage is that programs with large static
data structures which don't use them except for very large
problems can still run on smaller machines. Of course, a
program can also run out of disk space part way through
execution, but I'd personally prefer that.
With JLRU, disk space for all virtual memory is allocated
immediately.
Spice is a dusty-deck FORTRAN program with large COMMON
blocks. When you invoke Spice, disk space is allocated
to store the contents of the COMMON blocks.
This doesn't help, but at least now you know why...
Dave Erstad
DERSTAD@cim-vax.honeywell.com
Honeywell SSEC
Where, oh where, has my Aegis gone? Oh where, oh where can
it be?lwa@osf.org (Larry Allen) (02/06/90)
To be fair (but then, who ever said the world was fair? :^) and in defense of SR10, the behavior of requiring backing storage space for all allocated virtual memory is not only there for JLRUness, as Dave implies. The fact is, Apollo received a fair number of complaints from customers, especially system vendors, who found it difficult to write applications that would be robust in the face of running out of disk space. The problem is that the allocation of virtual memory (eg. via the UNIX malloc(), or via various Aegis calls) would apparently succeed, but when the process attempted to touch the memory (and hence had to actually allocate the disk space for the backing storage), the disk would be full and the touch would fail. Unfortunately it's very difficult to handle a disk-full condition at this point (in the middle of a page fault); the only recourse the OS has is to send a signal to the process. Writing an application that can deal robustly with an effectively asynchronous signal that can occur during the first touch of any portion of an allocated data structure is extremely difficult. So, in SR10 we took the much more conservative approach of requiring preallocation of backing storage for all allocated virtual memory. As Dave notes, this adversely affected some applications (eg old Fortran programs) that allocated huge amounts of virtual memory not intending to ever use most of it. I left Apollo about a year ago, so I'm not sure what (if anything) they've decided to do about this. Off the top of my head, the only thing I can imagine is some kind of option (perhaps a per-object-file stamp??) that tells the OS "for this application, don't preallocate backing storage". This seems pretty ugly and hard to administer, as well as being pretty non-obvious to the "average user". In any case, it's a very hard problem. It's a general case of the problem "how do you allow maximum utilization of a limited resource without running the danger of overcommitting the resource and without risking deadlock due to resource contention?" -Larry Allen Open Software Foundation
derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (02/07/90)
> I believe that there is an unanounced switch to /com/bind > that can be used to get old Aegis style memory management. > Try contacting rps@apollo.com to get the details. > > (I think the switch may be something like "-vm_sparse" > or some variation on that). The binder switch is -SPARSE_VM I can't speak for how well it works, though. Dave Erstad DERSTAD@cim-vax.honeywell.com Honeywell SSEC
achille@cernvax.UUCP (achille petrilli) (02/07/90)
In article <3322@paperboy.OSF.ORG> lwa@osf.org (Larry Allen) writes: >To be fair (but then, who ever said the world was >fair? :^) and in defense of SR10, the behavior of >requiring backing storage space for all allocated >virtual memory is not only there for JLRUness, as >Dave implies. The fact is, Apollo received a fair >number of complaints from customers, especially >system vendors, who found it difficult to write >applications that would be robust in the face of >running out of disk space. The problem is that the I really couldn't resist to answer to that. What we feel here, as a big Fortran shop, is that Apollo just didn't think of what they were doing. Why ? Well, until FTN90 gets approved and some implementations of it become available and people start converting (I mean, really using the new features of F90), there is NO standard way of getting rid of the big common blocks that should be dimensioned for the worst case ! So, that's why I believe Apollo completely overlooked (some of) its customers wishes/needs. Of course, as our FTN programs run, and must run, on many different OSs, some of 'em hopelessly obsolete, we cannot use system dependent dynamic memory allocation. I do believe that this change has done a lot of harm to many people. On the C side, things are much better. Traditionally dynamic memory allocation has been widely used in C programs. So I guess this is not a big problem and, as you state, the JLRU behaviour is actually better than the Aegis one. I think the real problem is that the JLRU behaviour has "cured" two distinct, and vaguely related problems: 1) dynamic memory allocation (where I fully agree with JLRU), 2) static memory allocation. 1) is fine under sr10. But 2), I'd prefer to get an option to be able to define how to treat it. Even if such an option would be available at boot time (say, as an environment variable that is only effective if set while running /etc/rc), it'd be better than today's situation. Also, your idea of a compile time stamp to indicate the preferred behaviour is a good one, but it may be a little to complicated. Cheers, Achille Petrilli