[movitz-devel] The reactions of gc to hard-drive reads

[Elliott]

Hi movitz-devel,

I got movtiz/losp/tmp/harddisk.lisp to function phyically here 
on an old pentium-mmx 166.  Hats off to Peter Minten!  Here are 
some timed examples of reads and writes to an old Conner drive:

Hard Drive Reads of 62 Sectors:
1) 5968041 cycles  	; The first read always takes around 4-5 times the cpu cycles as the others
2) 1713900 cycles
3) 1641908 cycles
4) 1649971 cycles
5) 2291781 cycles

   Average of first 5 reads: 2,653,121 cycles

Hard Drive Writes of 62 Sectors:
1) 1023253 cycles
2) 1315208 cycles
3) 1325826 cycles
4) 1321191 cycles
5) 1324301 cycles

   Average of first 5 writes: 1,261,956 cycles


Unfortunatly I had to reboot a few times to get the fifth read
because of a nasty situation that seems gc related.
This is the exception here:

";; Handling out-of-memory exception ..
 Error: Scanning an infant object #x55e23 at #x3eaff (end #x3eb0c)" 

Other times gc seems to be working just fine, it reports just like
this:

";; Handleing out-of-memory exception ..
 ;; Old space: 255.6 KB, new space: 127.3 KB, freed: 128.3 KB."

That situation is almost worse than the above exception, because after 
a few more read-write-read-write tests the gc starts trying to free 
memory, which for some reason it can't.  I've had moments where the 
screen goes black and the kernel is unresponsive (I'll look into a 
"magic sys-Rq" key or something) and other times where it will stream 
the following down the screen:

";; Handling out-of-memory exception..
 ;; Old space: 255.6 KB, new space: 255.6 KB, freed: 0 KB" 

Of course the memory issue only appears on reads, when data is 
ingested and reads occupy nearly twice the cpu time as writes. I'm not
exactly sure of why that is, but gc could be playing a role.  Is this 
a bug, or does los0's gc just not recognize the accumulation of long 
vectors from the harddisk as collectable data?

Another situation concering gc and the harddisk.lisp file is the length of 
these vectors.  I havn't tested this with writes, because it requires 
makeing a vector larger than 62 sectors, but when using the command 
(hd-read-sectors 0 0 63) I get another exception, this one with
INIT::CLUMPS which seems to be part of los0-gc.lisp.  Here is the exception:  

"Error: The value of INIT::CLUMPS, #x3f01, is not of type (INTEGER #x0 #x3e80)."

Useing (concatenate 'vector * *) after issueing a (hd-read-sectors 0 0 32) to
generate a vector of length 64 I still get this error, so it must do with the 
length of a vector.  All of these issues maybe related, but I don't know enough 
of how los0 functions yet to be sure or know even if they truely are.

I've build a few images with the latest from cvs and each has performed the same.
I've posted my latest image here at http://ejohnson.ggservers.com/los0-image   

Please test it out if you can to see if the problem is local to my image or 
hardware.

Thanks guys!

-Elliott