Day 15 — CS Fundamentals December — About Operating Systems — Memory Management-2

Yashvardhan Kukreja
5 min readDec 16, 2019

So, in yesterday’s article (Day 14), I wrote about the introduction to memory management and the problem of fragmentation while managing memory in computers.

But I didn’t write about two sub-topics in that article because they are so important that they deserved an article solely dedicated for them.

So, here is that article, where I am going to be writing about Paging and Segmentation, the two key incontiguous memory allocation techniques in memory management.

Let’s dive in!

This article won’t have an introduction because previous article itself was its intro, so check that out :P

Paging

So, there exists a way by which a computer can “utilize” more memory than the actual available physical memory on the CPU.

Sound weird right? But that’s true!

This extra amount of memory is called virtual memory and this extra memory is, basically, your hard disk’s memory emulating to be computer’s RAM.

And Paging technique plays a crucial role in implementing this virtual memory.

So, first of all, let’s understand two things required to, in turn, understand Paging:

  • The process’s address space (basically, the process itself) is divided into blocks/segments of same size. And each block/segment is called a page. And the size of each page is a pre-determined power of 2 between 512 bytes and 8192 bytes.
  • Similarly, the main memory (RAM) is divided into blocks/segments of same size. And, here in RAM, each such block/segment is called a frame. And the size of each frame is usually kept same as the size of each page so as to make sure optimal utilization of RAM and a good avoidance of external fragmentation.

Before anything else, let’s talk briefly about addresses (please don’t freak out, I got your back!)

So, there are two kinds of addresses involved with Paging:

  • Page address or Logical address: It is represented by page number and page offset. Page offset is the size of the page block in the process.
Page address/Logical address = Page number + Page offset
  • Frame address or Physical address: It is represented by frame number and frame offset. Frame offset is the size of the frame block in main memory.
Frame address/Physical address = Frame number + Frame offset

Now, Paging involves allocating each page to a frame which involves mapping that page’s address to the respective frame’s address.

So, there is a table called Page Map Table which is used to keep track of the mappings between page addresses/numbers with the respective frame addresses/numbers.

So, how does paging work?

So, when the OS allocates a page to the frame, it maps and translates the logical address of that page to the physical address of that frame.

And then, this leads to creating an entry in the Page Map Table for the above mapping which is going to be used throughout the execution of the program.

So, now, whenever a process is supposed to be executed, its corresponding pages are allocated into the freely available frames in the main memory (RAM).

PS: draw.io is an amazing tool :’)

Now, the main role of paging (and hence, virtual memory) comes in when the program requires more memory than the freely available main memory.

Then, paging comes into the play where the OS moves the existing idle and unwanted pages from main memory to the hard disk so as to clear up RAM for the incoming process and then, brings back the removed pages whenever required in the future by “swapping” some other unwanted page in that moment.

This process of unloading the idle unwanted pages from main memory to hard disk and, bringing in and loading the required pages into the main memory, keeps on happening until the entire execution of the program.

This loading and unloading is called swapping. And due to the equal sizes of the frames and pages, swapping becomes very optimal and easy.

One of the problems with paging though is that the page map table itself requires some main memory space which is not good for computers with small RAMs.

Segmentation

It is kind of similar to Paging.

So, here, the process is divided into variable-sized segments (unlike Paging where pages are fixed-size) where each segment is meant to perform a dedicated function or module. Each segment is actually a different logical address space of the program.

Each segment is mapped to a region (group of memory blocks) of the main memory in an incontiguous manner.

And, a Segment Map Table is maintained which involves entries depicting the size and memory address of each respective segment.

The memory address is the starting address of the segment in the main memory.

PS: Again, draw.io is a beautiful tool :’)

Now, when the process is brought about to execute, then the corresponding segments are allocated to the memory in incontiguous fashion (remember incontiguous memory allocation).

But the each segment in itself is loaded in main memory in contiguous frames.

“Wait what? So, it is contiguous or incontiguous, Yash?”

Okay! In the above diagram, look at the main memory carefully. The segments are arranged incontiguously in the main memory. In the main memory, The blue part (segment 1), the green part (segment 2) and the yellow part (segment 3) are arranged incontiguously due to the empty blocks in the middle (900 address and 300 address).

But zoom into the individual segments, in the memory. For example, the segment 2. It, in itself, is allocated memory blocks in the main memory contiguously from address 400 to 800 (its size = 900).

So, that’s what I meant and that, basically, depicts the working of Segmentation.

That’s it!

Thanks for reaching till here!

I hope you understood the article and got a good idea of Paging and Segmentation about their working.

Stay tuned for another article which is going to come tomorrow associated with some other interesting CS fundamental.

LinkedInhttps://www.linkedin.com/in/yashvardhan-kukreja-607b24142/

GitHubhttps://www.github.com/yashvardhan-kukreja

Email — yash.kukreja.98@gmail.com

Adios!

--

--

Yashvardhan Kukreja

Software Engineer @ Red Hat | Masters @ University of Waterloo | Contributing to Openshift Backend and cloud-native OSS