Now this obviously was an effort to improve our understanding of the existing kernel. We hoped that FIFO with new preloading will really be pathetic in all the cases. But this wasnt the case. The original scheme was consistent in most of the cases but failed by almost 20% when i accessed an insanely large linked list. I ofcourse could not use stack as there is a serious size limitation associated with it... also I was not sure whether the stack frame associated with a process resident in the memory is paged out.... i think it wont be... but thats the logical implication... i needed empirical data to assert somethings for the experiment...
Any way FIFO was way better than LRU for that particular case. The graphs for all the different cases proved a lot of theories which I had read and broke many myths and assumption I had about the system. The best one is this...
struct node *next;
int info; //page size in FreeBSD4.1
struct node *first,*curr,*temp;
first=(struct node *)malloc(sizeof(struct node));
add temp to first...extend the linked list .//too lazy to type
}while(there is still space in the heap);
Now guess the amount of page faults....just 400. And as soon as you write to it the pf shoots up to 45000. My best bet is that the system implements some kind of copy on write. The memory is allocated on heap only when something is written onto it or read from it...not before.
There were plenty of obscure facts that never failed to baffle me. All the budding kernel hackers should definitely take a look at BSD kernel. Simple yet powerful...