Thank you all for the responses. Russell's answer was the most clear one and I think everybody can have benefith of reading this. Not only those who don't know, but also the for the once already know it can be refreshing to read this one: A process running on a typical 32 bit system is allowed to address 4Gb of memory. There is a really huge amount available to it on a 64bit system. This memory isn't really there, so it is called "virtual memory". The range of available addresses in virtual memory is called the process's "address space." Most of the time the process will be holding only a few pointers into different parts of it's address space and will be attempting to read and write memory through those pointers. All of these memory accesses are intercepted by the operating system (OS) which maps the "virtual" address the process in using to a real address in RAM. Obviously there isn't enough RAM on most computers to even do a one-to-one mapping from the processes virtual addresses to a physical address. Fortunately, because the process can only access it's address space through pointers, it can only access a few addresses at a time. Moreover, generally each new access is to an address that is near the most recent access. Statistically, most of a process's pages will only get accessed once. However, in the short run there will be a small block of pages that are being accessed frequently, because most programs contain loops, and repeatedly read certain pages. Only rarely, (hopefully!) a process will access a page that it last accessed a relatively long time ago. Here is how the OS manages all of this: 1. Chunks of real memory are allocated to the process in pages. On Solaris, the page size is 4096 bytes. Each page is timestamped whenever a process references it. If the process writes on the page it is marked as "dirty". 2. Periodically a kernel process called pageout (PID=2) sweeps through physical memory and moves pages that haven't been accessed by a process for a long time to a free list. These times are in the order of tens of seconds. During a memory shortage, the sweep rate increases. 3. If there is a shortage of physical memory, the oldest, dirty pages in the free list get written onto the swap device. When a process accesses a virtual address, one of three things can happen: !. The corresponding physical page is in memory. The access succeeds. 2. The page is not in memory - but it is on the disk. This is called a "major fault". The process is blocked and a context switch occurs. While the process is waiting, the page is brought off the disk into memory, the processes Hardware Address Table (HAT) is updated and the process is marked "runnable". 3. The page is no longer mapped into the process, but is on the free list. This is called a "minor fault." (I got there at last!) In this case a context switch still occurs and the page is removed from the free list and mapped back into the process. There is a more light-hearted explanation here: http://www.netjeff.com/humor/item.cgi?file=TheThingKing Again, Thanks Russell. Regards, Rick =========================================================== De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is alleen bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. Hoewel Orange maatregelen heeft genomen om virussen in deze email of attachments te voorkomen, dient u ook zelf na te gaan of virussen aanwezig zijn aangezien Orange niet aansprakelijk is voor computervirussen die veroorzaakt zijn door deze email. The information contained in this message may be confidential and is intended to be only for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Although Orange has taken steps to ensure that this email and attachments are free from any virus, you do need to verify the possibility of their existence as Orange can take no responsibility for any computer virus which might be transferred by way of this email. =========================================================== _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Mon Aug 1 04:52:29 2005
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:50 EST