🚀 go-pugleaf

In article <1992Apr10.055227.5274@cubetech.com> andrew@cubetech.com (Andrew > 
> Paging in itself is fast, but it's real speed is totally dependant on how  
much  
> data you can blast to the disk.  Your problem is that you are just pushing  
your  
> scsi port and devices to the absolute limit.  First you RIP part of the  
output  
> image and separate it into RGB.  While you do that, you run out of memory and  
> mach pages most of it to disk.  Then you start to blast it to the imaging  
> device.  Well, eventually you'll start trying to send data that has been  
> swapped to disk, and a page fault occurs, so while you are trying to blast  
this  
> stuff out the SCSI port to the imaging device, mach is desparately trying to  
> retrive the data you want from the same SCSI port and a slow disk AND it's  
> trying to page out old data that you aren't going to use anymore anyway.   
Well,  
> mach and your software end up beating eachother senseless trying to use the  
> port.  Mach gets priority, but will let your app blast more data out the scsi  
> port as soon as it can get some off disk.  Effectively, the machine just  
grinds  
> down to glacial speeds.
> 
> What you need to do is make memory transfers.  You need to structure your  
> driver so it sends everything it can in real memory to the imaging device and  
> then deallocates that memory.  So try to figure out how much real-memory you  
> can take over without stepping on the toes of something that might want to  
> access the memory.  You can probably assume that the NeXTstep apps are going  
to  
> remain inactive the entire time you are imaging.  So allocate as big a chunk  
of  
> page-aligned memory as you can without it going to disk (the first time you  
do  
> it, everything else will be paged out) RIP and split, send it, then  
deallocate  
> it.  Now there should be a nice big block of free real-memory unless  
something  
> else on the system decides it wants memory, so allocate more and totally fill  
> real-memory.  Then send that big block to the imaging device.  If you do it  
in  
> nice big chunks like this you should get a hell of a lot more speed than  
having  
> your app fight with mach for a single page of memory.  You also have to get  
rid  
> of memory as soon as you don't need it or mach will page it back out to disk  
> which is what you don't want.

You're right, paging in itself is fast, but the mach VM system is slower than  
hell.  In fact, the VM system on the NeXT is so bad, NeXT itself has been  
targeting that area as one of the number one points it is working on at the  
moment.  As for my imaging uses, I don't use VM anymore, I have had to find a  
way to skirt the VM because of that exact reason you stated (ie, the SCSI  
fighting itself).  But the fact remains, even if the the VM file is half empty,  
it not freeing itself is bull.  If that is correct, then the previous analysis  
is correct, we're talking serious boat anchor time, because the i-node for the  
damn swapfile will always reserve the 90+MB's (or whatever the size) on the  
disk, thus totally cutting the disk size down, and slowing the process time.  A  
dynamic swapfile, as apposed to the static swapfile we have now, is a very good  
start on the way to an answer.

J. Alexander Jamison
Sr. Systems Engineer
Talus Imaging and Communications Corp.