Forums

virtual memory

Started by khan May 9, 2006
I want to clear my virtual memory concept.
Is virtual memory, a part of hard disk or NAND Flash (some indirect
addressable memory).

http://en.wikipedia.org/wiki/Virtual_Memory
are you comfusing memory swap with VM?

"khan" <mushtaqk_921@yahoo.co.in> wrote in message
news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
> I want to clear my virtual memory concept. > Is virtual memory, a part of hard disk or NAND Flash (some indirect > addressable memory). >
"khan" <mushtaqk_921@yahoo.co.in> wrote in message 
news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
>I want to clear my virtual memory concept. > Is virtual memory, a part of hard disk or NAND Flash (some indirect > addressable memory). >
Virtual memory is frequently on a hard disc but is probably not in NAND flash. Virtual memory is memory that isn't really there. Say you have 16MB of RAM, 100MB of Hard disc and a 32MB of data you want in memory. The first 16MB would go into RAM and then a virtual memory controller would store the remaining 16MB on the hard disc in an file reserved as "Virtual Memory". The program accessing the data will not know or care whether the memory it is accessing is in RAM or on the disc - it all looks the same from outside. It is not impossible for the virtual memory area to be in a NAND flash but if I would tend to use something that doesn't wear out as it is written to.
"khan" <mushtaqk_921@yahoo.co.in> wrote in message 
news:1147169261.671107.89850@i39g2000cwa.googlegroups.com...
>I want to clear my virtual memory concept. > Is virtual memory, a part of hard disk or NAND Flash (some indirect > addressable memory). >
Virtual memory could be both but it is always a bad idea to use flash memory. You'll wear it out very fast. http://en.wikipedia.org/wiki/Virtual_memory Peter
Tom Lucas wrote:
> "khan" <mushtaqk_921@yahoo.co.in> wrote in message > news:1147169261.671107.89850@i39g2000cwa.googlegroups.com... >> I want to clear my virtual memory concept. >> Is virtual memory, a part of hard disk or NAND Flash (some indirect >> addressable memory). >> > > Virtual memory is frequently on a hard disc but is probably not in NAND > flash. Virtual memory is memory that isn't really there. Say you have 16MB > of RAM, 100MB of Hard disc and a 32MB of data you want in memory. The first > 16MB would go into RAM and then a virtual memory controller would store the > remaining 16MB on the hard disc in an file reserved as "Virtual Memory". The > program accessing the data will not know or care whether the memory it is > accessing is in RAM or on the disc - it all looks the same from outside. > > It is not impossible for the virtual memory area to be in a NAND flash but > if I would tend to use something that doesn't wear out as it is written to. >
No, you are confusing virtual memory with swap space. The concepts are related, but not identical. In particular, you can have virtual memory without swap space, but not vice versa. The terms "physical memory" and "physical addresses" refer to actual memory connected to the processor and directly accessible by it. This is what is meant when you say a system has, say, 256 MB ram. The physical address range is limited by the number of address pins (or chip selects, or sdram address range, or whatever). The physical address is therefore the address seen by the memory hardware. The "virtual address", on the other hand, is the address seen by software, which can be quite different. There are three possible reasons for making it different - one is to give the software the illusion that it has access to more memory than the system has physically, another is to give the software the illusion of a single contiguous memory block even if the physical memory mapped to the virtual memory is piecewise, and the final reason is to ensure that separate applications have separate memory spaces. A virtual memory system can implement any or all of these systems, with only the first requiring swap space.
On Tue, 9 May 2006 11:26:28 +0100, "Tom Lucas"
<news@REMOVEautoTOflameREPLY.clara.co.uk> wrote:

>It is not impossible for the virtual memory area to be in a NAND flash but >if I would tend to use something that doesn't wear out as it is written to.
NAND flash could be used to load read-only pages (such as code) directly into physical RAM in demand paging. If the physical RAM becomes full and some pages must be discarded, read-only pages can be discarded and loaded again from the original store (e.g. executable file). However, modified "dirty" pages needs to be saved into a secondary store (page file) if these pages must be removed from physical RAM to make room for other pages. The page file should not be on the Flash, since the frequent writes to the page file would destroy it quickly. Unfortunately some operating systems have a tendency to try to purge pages from physical RAM just as a precaution even if the physical memory would be much larger than the sum of all programs ever executed in the system. Thus desktop operating systems should not moved to a Flash only system without doing something to the page file mechanism. Paul
David Brown wrote:
>No, you are confusing virtual memory with swap space. The concepts are >related, but not identical. In particular, you can have virtual memory >without swap space, but not vice versa.
This is not correct. I have worked with a RTOS on Hewlett-Packard minicomputers that did not have any support for virtual memory, (no MMU, no traps on accessing invalid addresses, no restartable instructions, etc.) but did support swapping. At "sysgen" (system configuration) time you could partition the memory not used by the OS itself into non-overlapping regions. When linking a program, you had to tell what region it should use. More than one active program could use the same region, (i.e. they were linked to use the same physical memory,) and the OS would swap them in and out (to disk) as needed. This was a standard technique before MMUs became common place, as well as support for "Program Overlays", which we could call a poor man's swapping mechanism. (Anybody still using overlays?) Roberto Waltman
On Tue, 09 May 2006 10:01:06 -0400, Roberto Waltman
<usenet@rwaltman.net> wrote:

>David Brown wrote: >>No, you are confusing virtual memory with swap space. The concepts are >>related, but not identical. In particular, you can have virtual memory >>without swap space, but not vice versa. > >This is not correct. I have worked with a RTOS on Hewlett-Packard >minicomputers that did not have any support for virtual memory, (no >MMU, no traps on accessing invalid addresses, no restartable >instructions, etc.) but did support swapping. >At "sysgen" (system configuration) time you could partition the memory >not used by the OS itself into non-overlapping regions. When linking a >program, you had to tell what region it should use. More than one >active program could use the same region, (i.e. they were linked to >use the same physical memory,) and the OS would swap them in and out >(to disk) as needed.
>This was a standard technique before MMUs became common place, as well >as support for "Program Overlays", which we could call a poor man's >swapping mechanism. (Anybody still using overlays?)
I'll add my own experience with HP 201x processors and their timesharing system. It also did swapping without any virtual address system involved. A portion of the main CPU memory (there was an IO processor with half the memory, as well), was reserved for the program space and the rest for the timesharing system. In addition, various 'commands' were also loaded into the swap space for their execution, allowing for extending the operating system features. Not only was their no virtual memory, there was no hardware support for a stack. I suspect similar things were done on PDP-8s and other computers of that day and earlier, such as the IBM 360. Jon
> I suspect similar things were done on PDP-8s and other computers of > that day and earlier, such as the IBM 360.
I have done similar - to an extent - things later (mid 90-s) on a 68340 CPU. It had no MMU, but the OS - DPS, which now happily runs on a PPC with an MMU and normal VM - did have dynamic memory cluster allocation from day one. What I did was provide a call (actually a set of calls) for the applications which would allow them to knowingly release (typically large) regions of memory when they did not need them for some time so this memory could be allocated to other tasks (being written to the swap file before that). The application which had released a memory region could claim it back using a call and would get it again contiguosly allocated although perhaps placed at some other address (obviously the code had to be written to take that into account, not a big issue since the actual address was returned by the call). The PPC version actually still supports all that - same old sources - but only old applications use it, I have not (yet?) written new ones to use this mechanism. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Jonathan Kirwan wrote:
> On Tue, 09 May 2006 10:01:06 -0400, Roberto Waltman > <usenet@rwaltman.net> wrote: > > >David Brown wrote: > >>No, you are confusing virtual memory with swap space. The concepts are > >>related, but not identical. In particular, you can have virtual memory > >>without swap space, but not vice versa. > > > >This is not correct. I have worked with a RTOS on Hewlett-Packard > >minicomputers that did not have any support for virtual memory, (no > >MMU, no traps on accessing invalid addresses, no restartable > >instructions, etc.) but did support swapping. > >At "sysgen" (system configuration) time you could partition the memory > >not used by the OS itself into non-overlapping regions. When linking a > >program, you had to tell what region it should use. More than one > >active program could use the same region, (i.e. they were linked to > >use the same physical memory,) and the OS would swap them in and out > >(to disk) as needed. > > >This was a standard technique before MMUs became common place, as well > >as support for "Program Overlays", which we could call a poor man's > >swapping mechanism. (Anybody still using overlays?) > > I'll add my own experience with HP 201x processors and their > timesharing system. It also did swapping without any virtual address > system involved. A portion of the main CPU memory (there was an IO > processor with half the memory, as well), was reserved for the program > space and the rest for the timesharing system. In addition, various > 'commands' were also loaded into the swap space for their execution, > allowing for extending the operating system features. > > Not only was their no virtual memory, there was no hardware support > for a stack. > > I suspect similar things were done on PDP-8s and other computers of > that day and earlier, such as the IBM 360. > > Jon
David Brown wrote:


> > The "virtual address", on the other hand, is the address seen by > software, which can be quite different. There are three possible > reasons for making it different - one is to give the software the > illusion that it has access to more memory than the system has > physically, another is to give the software the illusion of a single > contiguous memory block even if the physical memory mapped to the > virtual memory is piecewise, and the final reason is to ensure that > separate applications have separate memory spaces. A virtual memory > system can implement any or all of these systems, with only the first > requiring swap space. >
When did memory management become synonymous with VM? There were memory management units in computers since the early 1960s and except for systems which implemented VM (eg. S/360) they did not use the terminology "virtual address". BTW, a well-known example of swapping without VM was implemented on the CDC 6000 series running SCOPE or derivatives; tasks or jobs were rolled in or out from a control point by the operator or automatically by job control (under supervision by a PPU program). Michael Grigoni Cybertheque Museum