This picture could be found on Operating system concepts, beginning of Chapter 9. The size of virtual address space is 0 to max. My question is:
what will decide the max value? Is it fixed?
what will happen if the hole between stack and heap is filled and one of them of both of them want to grow continually?
I know that my question may be duplicate, but I've read a lot threads and I still cannot get my answer. Thanks in advance!
Keep in mind that what you are seeing is a very simplified diagram of what happens. First of all all, the underlying hardware sets a maximum logical address range.
Some part of that range will be reserved (either through hardware or software, depending upon the processor) for the operating system. The remaining addresses are for the user address space.
So what you are looking at is a conceptual view of a user address space. This can be further limited by system parameters and process quotas.
what will decide the max value? Is it fixed?
Thus MAX is a combination of hardware limits, operating system address allocation, system parameters, and process quotas. It can, therefore, be unfixed.
what will happen if the hole between stack and heap is filled and one of them of both of them want to grow continually?
First of all remember this diagram is only conceptual. One simplification is that the valid addresses within the address space need not be contiguous. There could be holes. Second, memory layout is usually controlled by the linker. The "text" and the "data" can be reversed or even interleaved.
The blue "hole" will generally be unallocated (invalid) memory pages. Some OS's do not grow the stack. It is preallocated by the linked. In a multi-threaded system, there could be multiple stacks (another simplification of the diagram) and there are often multiple heaps.
As various function map pages into the logical address space, the blue area shrinks. If go goes to zero, the next attempt to map pages will fail.
Related
This question already has an answer here:
Minimum associativity for a PIPT L1 cache to also be VIPT, accessing a set without translating the index to physical
(1 answer)
Closed last year.
Homework question, so please just nudge me in the right direction.
Consider a system with physically-addressed caches, and assume that 40-bit virtual addresses and 32-bit physical addresses are used, and the memory is byte-addressable. Further assume that the cache is 4-way set-associative, the cache line size is 64 Bytes and the total size of the cache is 64 KBytes.
What should be the minimum page size in this system to allow for the overlap of the TLB access and the cache access?
I've been stuck on this question and have no idea how to even begin. Can someone give me a hint towards finding the solution?
I think the most important piece of information in the question is
overlap of the TLB access and the cache access
This means, we access the Cache at the same time we access the TLB. In practice, what we really do is, we index the cache with the index bits from the virtual address and by the time we have located the entry in the cache, we will have the data (physical address) from the TLB. Then we can do the tag comparison with physical address. In other words cache acts as a Virtually indexed, Physically tagged (VIPT) cache.
Even though the scheme sounds efficient, the thing to lookout is, number of bits used to index the cache, cannot be higher than the number of bits needed to represent the page size. Simply, size of a page can put an upper limit on the number of cache entries.
Now coming back to your question,
its a 64KBytes cache with 4 way set assoc. and cacheline of 64Bytes.
Number of cachelines = (64KBytes/4)/64Bytes = 2^8 cachelines
That means if a page is 256Bytes or bigger, we can use this mechanism. If a page is smaller than 256 Bytes, then we cannot assume the index bits of the virtual address and the physical address are going to be the same.
What should be the minimum page size in this system to allow for the
overlap of the TLB access and the cache access?
256Bytes
I am trying to understand both paradigms of memory management;however, I fail to see the big picture and the difference between both. Paging consists of taking fixed size pages from a secondary to a primary storage in order to do some task requested by a process. Segmentation consists of assigning to each unit in a process an address space, so they are allowed to grow. I don't quiet see how they are related and that's because there are still a lot of holes in my understanding. Can someone fill them up?
I think you have something confused. One problem you have is that the term "segment" had multiple meanings.
Segmentation is a method of memory management. Memory is managed in segments that are of variable or fixed length, depending upon the processor. Segments originated on 16-bit processors as a means to access more than 64K of memory.
On the PDP-11, programmers used segments to map different memory into the 64K address space. At any given time a process could only access 64K of memory but the memory that made up that 64K could change.
The 8086 and it successors used segments with base registers. Each segment could have 64K (that grew with the processors) but a process could have 4 segments (more in later processors).
Paging allows a process to have a larger address space than there is physical memory available.
The 8086's successors used the kludge of paging on top of segments. However, that bit of ugliness has finally gone away in 64-bit mode.
You got your answer right there, paging relates with fixed size pages in a storage while segmentation deals with units in a page. 'Segments' are objects in the class 'Page'
I faced this question in my interview, I answered that, there is no limit, as virtual memory itself imaginary thing, so we don't have any limit.
But I don't understand any proper answer by googling.
Kindly help me out in this and explain the memory limit of virtual memory.
The maximum theoretical size for virtual memory is given by the size of a pointer. The largest number that can be represented by the pointer is the maximum theoretical size of virtual memory. The units are the minimal addressable memory unit (typically bytes).
Real operating systems sometimes impose additional restrictions.
There are a number of restrictions on virtual memory.
The address range of the underlying hardware.
Any subdivisions of the address space. Some ranges may be reserved (for example, System and User address spaces) Some may be invalid altogether. Example: VAX divides the 32-bit address evenly into 2 user spaces, a system space, and a reserved (unusable space).
Limits the operating system imposes on page table size. Must system have a parameter and/or account setting limiting this.
The size of the page file.
beginners question:
"If" paging is disabled and only segmentation is enabled (CR0.PE is set) then does that mean if a program is loaded in memory (RAM), its whole binary image is loaded and none of its "part" is swapped out, becoz a program is broken into fixed size chunks only when paging is enabled (which then can be swapped out). And if it's true this will reduce the number of processes that run in memory of a particular size of RAM, say 2 GB?
Likely, but not necessarily.
It depends on the operating system...
You could write an operating system that uses a segment to map a part of the program into memory. When the program accesses memory outside the segment, you get a segmentation fault. As the segmentation fault is then passed to the operating system, it could swap in some data from disk and modify segmentation information, before returning control to the program.
However, this is probably difficult and expensive to do, and i do not know of any operating system that acts in this way.
As to the number of processes - you need to split the available memory into contiguous parts, one for each process. This is easy if processes do not grow; if they do, you need padding and may need to copy processes around, which is rather expensive...
Most OSes use paging for virtual memory. Why is this? Why not use segmentation? Is it just because of a hardware issue? Is one better than the other in certain cases? Basically, if you had to choose one over the other, which one would you want to use and why?
Let's assume it's an x86 for argument's sake.
OS like windows and Linux use a combination of both segmentation and paging. The virtual memory of a process is first divided into segments and then each segment consists of a lot of pages. The OS first goes to the specific segment and in that segment it then locates the particular page to access an address
Taken from :operating systems concepts by galvin
one of the issues..
Segmentation permits the physical address space of a process to be non-
contiguous. Paging is another memory-management scheme that offers this
advantage. However, paging avoids external fragmentation and the need for compaction, whereas segmentation does not.
Segmentaion problem:
The problem arises because, when code fragments
or data residing in main memory need to be swapped out, space must be found
on the backing store. The backing store has the same fragmentation problems
but access is much slower, so compaction is impossible.
Paging solves it by:
The basic method for implementing paging involves breaking physical memory into fixed-sized blocks called frames and breaking logical memory into
blocks of the same size called pages.The backing store is divided into fixed-sized blocks that are the same size as the memory frames or clusters of multiple frames.
Since pages-frames-The backing store all are divided into same size so it doesn't lead to external fragmentation. But may have internal fragmentation.
So pagesize must be chosen correctly
Operating Systems concepts
Note, that Single-Address-Space Operating Systems sometimes use segmentation to isolate processes.