Received: from ukc.ac.uk by gos.ukc.AC.UK id a002499; 13 Nov 86 12:13 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a020200; 13 Nov 86 12:11 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Thu, 13 Nov 86 11:49:33 gmt From: Steve Thomas Date: Thu, 13 Nov 86 11:51:05 GMT Message-Id: <1381.8611131151@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: Re: [NZ]MAGIC Status: RO > > Demand paged text segments will live in the file systems, not the > > swap space. You'll get, effectively, more swap space if everything > > is demand loaded - maybe 1-1.5M in practice. > > >> other system performance? > > Demand-loaded processes are faster to start, but cause some additional > > overhead (probably less than 1%). If the text gets paged out & in, > > it will be from the file system, which may increase the average seek > > time. > > - Would not the need to copy the text out of the file system and into the > swap space increase the disk-write traffic rather than just loading it in > from the user filesystem? Possibly. It depends how memory-rich the system is. I would guess that the initial loading of text segments (whether directly for NMAGIC, or paged by ZMAGIC) is a small fraction of total disk traffic, and it won't make very much difference one way or the other. > - Gos only has one disk. since the head is buzzing vigorously anyway, > (recall how our disk is partitioned: root - swap - usr - users) does it make > much difference whether the stuff is in the usr or swap partition? On reflection, probably not. I had envisaged paging stuff from the end of the h partition, but I suspect you're mainly concerned with changing the stuff in root and /usr to be ZMAGIC. In that case, it won't make much difference. > Or is it easier to load when it is organised in the swap area? The main difference loading from swap or the file system is the seek time, I think, although there is a difference in the amount of code executed in each case. I wouldn't like to say which is easier. > - I am confused by the fact that attempting to overwrite an NMAGIC binary > while it is running results in "textfile busy". Why, if it has been copied > into swap? Something to do with the fact that there are potentially many processes using the text segment, I think, and updating them all is inefficient. Alternatively, I could be talking through my hat, and it's merely an historical accident. > >> - I am surprised that there is a text usage figure given by pstat. > >> Does this imply that there are old magic numbers about? > > Depends what you mean by old magic numbers. Essentially all binaries on > > the ORION are '410' or '413' type (actually 1410 or 1413). The former > > have read-only texts but the texts live in swap space when the process > > is running, because the blocks aren't suitably aligned in the file. > > By "old magic numbers" I mean OMAGIC. > Yes, a throwaway program reveals that there are. > /usr/lib/libdbm.a (??!) and stuff in /usr/lib/term. You get OMAGIC if you say cc -c ... libdbm.a isn't an archive, as such - it's just an ordinary module. The stuff in /usr/lib/term isn't executable; for some reason, the nroff font tables are created using cc -c. > ALSO the object files created by cmd's port of the Berkeley pascal interpreter. > I just leant back and gave him a poke about this, as it is probably the main > load on the machine. That may be the cause. > BTW, if you would like a function to do recursive descents of the unix > filetree, I have one to which you are welcome, part of my toolkit, > much faster than find and more general. Yes, please. Could you uucp it to hlh!/usr/spool/uucp, please. Steve   Received: from ukc.ac.uk by gos.ukc.AC.UK id a002559; 13 Nov 86 12:14 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a020217; 13 Nov 86 12:12 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Thu, 13 Nov 86 11:55:33 gmt From: Steve Thomas Date: Thu, 13 Nov 86 11:57:08 GMT Message-Id: <1436.8611131157@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: Re: problem with profiling Status: RO There were several problems with graphical profiling in the original 4.2 release, fixed in a recent update (called OTS 2.1). You (or one of your colleagues) should have been informed of the update a couple of months ago. It fixes lots of bugs. One of the problems was that the old profiling prologue, as generated by cc -p or cc -pg, was unsuitable for graphics profiling. You'll need /lib/ccom, /lib/{,m}crt0.o /usr/lib/{gcrt0.o,libc_p.a}, and /usr/ucb/gprof from the new tape to get everything working. Steve   Received: from ukc.ac.uk by gos.ukc.AC.UK id a018334; 12 Nov 86 17:50 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a023464; 12 Nov 86 17:49 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Wed, 12 Nov 86 17:35:39 gmt From: Steve Thomas Date: Wed, 12 Nov 86 17:36:46 GMT Message-Id: <1350.8611121736@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: Re: swap space and poor system performance Status: RO > We have a problem on one of our 4.2BSD orions, used for the second and > third year teaching. > > All programs say they have run out of memory, which I assume means that > it has run out of swap space. That's almost certainly the case. The 'no more core' message either means no swap space or a per-region limit has been exceeded. There is a hard limit of 32M bytes per region, and a settable soft limit of (typically) a few megabytes, but most processes shouldn't get near those. > pstat -s saith: > > 7992k used (664k text), 8552k free, 3200k wasted, 0k missing > avail: 8*512k 5*256k 9*128k 8*64k 23*32k 30*16k 296*1k Seems reasonable; used+free ought to be about 16.5M. Wasted is a slight misnomer. New processes can't use the wasted space, but existing processes can. > (this was not when it was running out of memory though) > > (Gos has 6M of physical memory) > > A couple of things: > > - disk partitions: of its fujitsu eagle we use partition a for root, > g for usr and h for /u (the users' files). > If we use partition e for /usr and add in d for another swap partition, > will 4.2 use these partitions sensibly or will it try to interleave > swapping between them (a pessimal strategy!) ? It will try to interleave the swap areas, which is ungood, as you say. It has been the subject of some discussion, but it's not very easy to fix the problem. > - Most binaries on the system seem not to be demand paged > What difference does demand paging actually make to > swap space usage? Demand paged text segments will live in the file systems, not the swap space. You'll get, effectively, more swap space if everything is demand loaded - maybe 1-1.5M in practice. > disk traffic? Very little changed. Non-demand loaded jobs have their text & data completely read in before they start. If a process doesn't use a page of its text or data before it exits (which is rare for a small job) then there's some unnecessary reading. > other system performance? Demand-loaded processes are faster to start, but cause some additional overhead (probably less than 1%). If the text gets paged out & in, it will be from the file system, which may increase the average seek time. > Why did you decide not to demand page everything by default? Demand-loaded images are larger than normal ones; the decision was basically to save space. > - Ok, three things then! I am surprised that there is a text usage figure > given by pstat. Does this imply that there are old magic numbers about? Depends what you mean by old magic numbers. Essentially all binaries on the ORION are '410' or '413' type (actually 1410 or 1413). The former have read-only texts but the texts live in swap space when the process is running, because the blocks aren't suitably aligned in the file. > thanks > Martin again That's OK. Steve   Received: from ukc.ac.uk by gos.ukc.AC.UK id a003048; 23 Dec 86 9:02 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a000337; 23 Dec 86 9:02 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Tue, 23 Dec 86 08:59:18 gmt From: Steve Thomas Date: Tue, 23 Dec 86 08:59:40 GMT Message-Id: <298.8612230859@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: Re: occam mcd Status: RO Without hardware mods, you probably have insufficient memory. I'll jog Tim to provide you with some incantations. Merry Christmas Steve   Received: from ukc.ac.uk by gos.ukc.AC.UK id a009883; 24 Dec 86 10:02 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a010539; 24 Dec 86 10:02 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Wed, 24 Dec 86 09:44:40 gmt From: Tim Robinson Date: Wed, 24 Dec 86 09:45:37 GMT Message-Id: <599.8612240945@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: occam on 4.2 ORION Status: RO You will need extra control store. We supplied boards recently for two of your machines and I believe at least one other has it already. You will need to use the -c option of ml. -c1000 will place the microcode at address 1000 (hex), which is the start of the second page. On 4.1 you probably say -r /sys.sym to ml which causes it to read the symbol file to pick up the external entry points in the standard code. You can't do this when the object code is going into a different page as you cannot 'call' across a page boundary. Instead you need to link with the library file mlib.mrl which will give you a second copy of the required routines in the second page. (Say -s mlib.mrl) Be sure you have the latest version of the library file (/usr/lib/mlib.mrl) or things will go badly wrong. You need the one from the 2.1 tar image tape. Merry christmas and good luck Tim Robinson   Received: from ukc.ac.uk by gos.ukc.AC.UK id a027304; 22 Dec 86 10:19 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a010146; 22 Dec 86 10:20 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Mon, 22 Dec 86 09:05:54 gmt From: Steve Thomas Date: Mon, 22 Dec 86 09:13:23 GMT Message-Id: <205.8612220913@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: Re: occam microcode on 4.2BSD orions Status: RO The amount of spare control store on a standard Orion depends somewhat on its age. You'll have either 4K or 16K words. The amount is printed on the diagnostic console on first boot, and appears via /etc/dmesg or /usr/adm/messages. The standard system takes a trifle under 4K. As to the runes, the simple answer is that I don't know. I'll pass your question to someone who does. Steve   Received: from ukc.ac.uk by gos.ukc.AC.UK id a019161; 23 Jan 87 12:32 GMT Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a022311; 23 Jan 87 12:31 GMT Received: from service.hlh.co.uk (service) by hlh.co.uk; Fri, 23 Jan 87 12:23:20 gmt From: Steve Thomas Date: Fri, 23 Jan 87 12:23:33 GMT Message-Id: <962.8701231223@service.hlh.co.uk> To: mg@ukc.ac.uk Subject: Re: OTS2.1 tape Status: RO We dispatched a parcel on 9th October 1986; it should have arrived on the 10th. The addressee was Des Caul. In the parcel was one tape and about 10 sets of manual pages. Try extracting the stuff from him. If you can't find it, we'll send another tape. Steve