The page cache caches pages of files to optimize file I/O. The buffer cache caches disk blocks to optimize block I/O.

Prior to Linux kernel version 2.4, the two caches were distinct: Files were in the page cache, disk blocks were in the buffer cache. Given that most files are represented by a filesystem on a disk, data was represented twice, once in each of the caches. Many Unix systems follow a similar pattern.

This is simple to implement, but with an obvious inelegance and inefficiency. Starting with Linux kernel version 2.4, the contents of the two caches were unified. The VM subsystem now drives I/O and it does so out of the page cache. If cached data has both a file and a block representation—as most data does—the buffer cache will simply point into the page cache; thus only one instance of the data is cached in memory. The page cache is what you picture when you think of a disk cache: It caches file data from a disk to make subsequent I/O faster.

The buffer cache remains, however, as the kernel still needs to perform block I/O in terms of blocks, not pages. As most blocks represent file data, most of the buffer cache is represented by the page cache. But a small amount of block data isn't file backed—metadata and raw block I/O for example—and thus is solely represented by the buffer cache.

See also my answer to What is the difference between Buffers and Cached columns in /proc/meminfo output?

This is a very complicated question.

Just as an example — the caching of NFS/SMB/File-system data once read — … because these features were put in — to speed up certain types of jobs and typical usage. Virtual memory was designed because processes typically have a lot of initialization code before they go into a loop doing thing. The memory that is no longer used — need not physically need to be used. This leads to swap area or the ability to get it from it’s original place if it really has not changed — like read-only data or read-only code.

Being able to quickly change the virtual memory from one process to another led to page tables.

If there were no virtual memory — then the processes would run faster. All the overhead for that would not need to occur. BUT — then you would need to compile everything needed and a multi-process or general purpose computer would be more difficult to create.

You will need to learn a lot of about the terminology used in the question to be able understand the question(s). Like — what are you trying to optimize — processor performance, memory usage, etc,

This question would take me hours and hours to answer … and it is different for different processors and even if the processor has a memory management unit.

Why is this question being asked?

The Linux kernel is a resource manager. It has an API sbrk() etc with which a running process indicates it's need for additional address space. Note that addresses generated by different processes are not unique but are mapped so as to select process specific memory. When the kernel exhausts total available ram, pages are released using various policies. Swap space is disk that can be used to copy dirty pages onto for later retrieval, so as to release pages for immediate consumption. Linux can also reload ram pages from executable files. Point is that a process never sees a pointer to swap space. It gets memory into it's own address space / page tables only. Linux reclaims all of a process's ram when it exit()s the child process. Like when you get the command prompt again. Your login session is not the process. Every program that you run is a process and has it’s own address space. Elegant.

The “swap space” is just a disk space in form of a partition or afile that had been filled (pre-written), usually with zeroes. The memory pages of a waiting process can be written out to it (paged out) and later read back (paged in) by the most internal Kernel routines.

When a process tries to allocate more memory than is available on the system, inactive or least used pages of other processes are swapped out and the memory is given to the hungry process. With the help of the CPU’s Memory Management Unit the Kernel can detect that the formerly “robbed” process tried to access the page that had been swapped out (page miss exception). In this case the Kernel reclaims a page from physical memory (a free one or swaps out page from a different process) and pages the missing page in for the process to continue to access the page that has been reloaded (paged back) into memory space of the process.

This is not visible to the running process normally. The only exception is the use of memory-mapped files (mmap).

Hence the paging, swap space, MMU and the Kernel play together, not having any “advantage” one over another. What can be discussed regarding “advantages” are different approaches (agorithms) to detect page activity, pick up a process to steal the physical memory page from and rearranging the process schedule under various process and memory stress levels.

The operating system is trying to follow the plan its programmers gave it to make the best use of memory.

It has to have some free memory in order to make allocations immediately. A network or disk device may need some storage and can't wait for cache or swap reclaim.

File cache can be cleared out easily, but that isn't always the best decision. What is a better use, to keep the file cache that's been used once a minute for the last hour, or to keep some memory page that was used by a program during system start two days ago?

It is obviously better to swap out the old program data and keep the file cache.

Memory “use” is more complicated than ordinary users understand and the reporting of memory use by various tools is neither very understandable nor consistent. So your claim that 1G of RAM is “not in use” could easily be false and you just aren’t seeing the use.

But even if 1GB if ram was really “not in use” when you looked, the use of swap is still valid because of previous use of that ram. You said “move … when” but I assume you didn’t really observe that. You observed “had previously moved to swap and then not moved back when …”

A running computer has stale anonymous ram use that once moved to swap has no good reason any time soon (or maybe ever) to get moved back.

Bottom line, Linux algorithms for managing memory, including decisions of when/what to swap, are quite good (far better than Windows) and the frequent user complaints about it represent misunderstandings about how OS’s manage memory.

If you don’t understand “anonymous” memory vs. “mapped” memory vs. “cache” memory, you don’t know enough of the basics to even understand an explanation of what is happening.

Windows is coded to invent lies about memory levels (free vs. used) in order to make ordinary users who don’t understand how it should work think it is all working as they expect (reduces annoying false problem reports). That gets real annoying when an expert is trying to manage an actual problem in Windows memory allocation and gets no direct info on what is really happening.

For an expert, Linux is also annoying because the mechanisms have changed and documentation not kept up. But that is only if you are trying to manage a system with difficult memory management issue, which is getting uncommon since ram is cheap.

Not every time, only when the allocator does not have enough available to satisfy the request (or with some allocators, when the allocation makes it short enough that it is worthwhile asking for more).

The OS can only supply entire pages. A good memory allocator asks as few times as it can to avoid the cost of system calls.

Most allocators that are any good request multiple pages at a time, because the system call to do so is expensive. Some will ask for hugepages if the process has been asking for lots of memory.

It all depends on the behaviour of the particular allocation algorithm, and there isn’t necessarily just one on the system; in fact, there is very likely more than one. There are three common malloc implementations (glibc, tcmalloc and jemalloc), and applications often also roll their own for some or all allocations.

This is a truly complex question.

I have often said that the hardware of a computer runs at a certain speed, and that speed used to be constant and not affected by the software. Maybe your CPU runs ‘faster’ when it has no threads to run, but then it will only be idle.

The effective performance is influenced by the speed of the hardware, by environmental factors, and by the job load, that is all the software that is currently running at some point in time. Linux and Windows have the drawback that whenever your create a process, an image is created in memory and it become eligible for CPU scheduling. By default, there is no batch queuing mechanism.

The Linux kernel is responsible for managing multiple parallel threads and for managing CPU cycles, memory, network bandwidth, etc. The system operator is really responsible and tries to tune the system for optimal performance. The more threads, the more CPU cycles, RAM, and I/O bandwidth the applications demand, the bigger the system overhead and the lower the efficiency.

Short answer: Adding RAM is the only way to decrease paging for the same program load.

Long answer: Memory is managed as a set of fixed-sized pages. To be accessed (as program or data) a page must be in RAM. The virtual memory system writes modified pages to the disk (“page out”) so the RAM may be reused quickly if needed. How often “dirty” pages are written depends on “memory pressure,” the demand for RAM vs. how much RAM is available. At low memory pressure the VM system doesn’t page out anything. As the memory pressure increases page outs happen faster and faster as the VM system tries to stay ahead of the demand for fresh RAM.

Lowering memory pressure reduces paging. Running smaller programs or adding more RAM are the only practical ways of lowering memory pressure.

If I understand your question, with swap on, why do you not see more available RAM.

The swap space is an overflow space, and it is not an extension of RAM.

When RAM gets full, and you have defined a swap space, Linux will move some functions or data to the swap space in order to free up the available ram. Generally, the algorithm for output to swap chooses low usage functions. These are functions not used for a relatively long time, and functions that are not pinned.

What is not sent to swap: Memory that has device drivers (real memory where virtual address is the real address)

Memory that is being used as a I/O buffer. A short duration pin of virtual memory that becomes pinned, and when the I/O is complete some milliseconds later, the memory is unpinned.

Pinned memory is virtual memory marked as not-swappable. As mentioned, some memory for device drivers needs real hardware memory, to function, not virtual memory. That memory is long term pinned.

Both physical and virtual memory are divided into fixed-size blocks called pages. This paging system allows efficient management of memory and enables the swapping mechanism between RAM and disk.

Virtual Memory Management : - Linux employs a demand-paging system, where virtual memory pages are only brought into physical memory when they are needed. The kernel uses a combination of physical memory (RAM) and swap space to create the illusion of a larger address space than physically available. When an application accesses a virtual memory page that is not currently in physical memory, the kernel retrieves it from swap space (if it's swapped out) or from the original data source.

Page Replacement Policies : - Linux uses various page replacement algorithms to decide which pages to evict from physical memory when it needs to make room for new pages. Pages that have not been accessed recently or are less frequently used are more likely to be selected for eviction.

Swappiness : - Swappiness is a kernel parameter that determines how aggressively the system swaps out memory pages to swap space. A higher swappiness value indicates a more aggressive approach to swapping, while a lower value means the kernel prefers to keep more pages in physical memory. Administrators can adjust the swappiness value based on system workload and performance requirements.

Memory Pressure Handling : - The Linux kernel continuously monitors memory usage and system performance metrics to detect memory pressure. When the system experiences memory pressure the kernel may trigger mechanisms such as page reclamation, memory compaction, or process termination to alleviate the pressure and maintain system stability.

The question is “Does Linux allocate at least an entire page whenever you request memory?”

That’s hard to answer because your question is using these terms conversationally (and loosely) and not technically (and precisely.)

First and foremost, Linux refers only to the kernel.

Secondly, you (a person) never request memory. An agent (a device driver, a program, a part of the kernel) acting on your behalf (sometimes very indirectly) will interact with the kernel to request memory, but not necessarily at the time a C library function like malloc() or calloc() is called - or even when the *nix APIs brk() or sbrk() are called.

Thirdly, most memory allocation (even by the kernel) is indirect - various pools of memory for different purposes are kept and it’s only when those pools grow is memory allocated by the virtual memory system - which does allocate things in pages (for whatever a page is for the virtual memory system.)

For user-programs, sometimes memory is not allocated (by the virtual memory system) until it’s actually referenced (read from, written to, or executed from.) User programs in Linux usually interact with with the kernel’s memory management when loading a program (with the exec() family of functions), sharing memory, modifying memory, growing the stack (i.e.: function calls), and growing the data segment (heap) - by requesting memory through malloc()/calloc() (directly or indirectly) that larger than can be satisfied by any already existing space being managed by the malloc()/calloc() functions.

Memory management through malloc()/calloc() may allocate memory internally in certain minimum chunks in order to optimize alignment for the CPU architecture - i.e.: for requests larger that a “double” (or perhaps a “double double”), the memory will be aligned on those boundaries meaning that there might be multiple different pools of aligned memory to allocate from - but that’s the C-library, not Linux doing that.)

As John answered context switch has nothing to do with the process swapping out, but there is one thing which kernel does intelligently for TLB flush during a context switch:

So, during a context switch instead of flushing and invalidating all TLB entries, we only invalidate TLB entries related to that particular process translation table entries.

Now how does we know how to do this ?
Based on the ASID value of the process(each process in linux will have a unique ASID value) we know which all TLB entries needs to be invalidated on context switch of that process.
Above answer is how it happens on ARM architecture, I assume this should be same for other archs as well.

When a process exits, the Linux kernel tracks which pages were allocated for that process by checking the page tables. The page tables contain information about the pages that were allocated, such as their physical address, the virtual address they are mapped to, and the permissions associated with them.

When a process exits, the kernel will first free any pages that are still in physical memory. This is done by marking the page table entries as not in use and then freeing the physical memory associated with the page.

For swapped pages, the kernel will check the page tables to see if the page is marked as swapped. If it is, the kernel will then free the physical memory associated with the page, and then free the swap space associated with the page. TO SUPPORT FOLLOW ME!

Um, it gets changed!

The approximate method for doing a write to a file is as follows. Each “open file” has a reference count active on the file itself, so the file cannot be truly deleted until the last copy is closed. Each open file also has a “seek point”. Then when a “write” call happens, it comes with a buffer and length of data to be written at the current seek point for that open file.

Next, the file system code in the kernel breaks up the write into units that do not cross page boundaries, so let’s just think about one such chunk. The file system code says “give me a pointer to page N of file F”. If the page is already in the page cache, the pointer is immediately returned. If the page is not in the page cache, the requesting process blocks and disk I/O is scheduled to read the requested page into the page cache.

Once the pointer to the page cache is returned, the requesting process copies the write data into the page cache page and marks that page “dirty”. The dirty mark requires that the page be written back to disk at some point.

If the write is for a complete page that is not in the page cache, you can skip the disk read and just return an empty page to be filled in.

Things are more complicated in real life because certain metadata operations must be written back to disk in a certain order to assure file system integrity in the event of a crash at a bad moment.

The key fact here is that the page cache is shared by all processes, so even if multiple processes have the same file “open” they all read and write the same set of pages.

PS There are additional complications if you think that all writes should be “atomic” in that each process that does a write would have to get write locks on all affected pages before writing any of them. I’m not sure systems do this, but they could.

PPS One very special case is “append” when one writes to the end of a file. These sorts of writes do need to be atomic, so that different processes can append to log files and not get a tangled mess. It is also important that only one process at a time “extend” a file by allocating new pages, since it would be bad to duplicate efforts.

The function responsible for the activation of a swap area is sys_swapon() and it takes two parameters, the path to the special file for the swap area and a set of flags.

The top-level function for reading and writing to the swap area is rw_swap_page(). This function ensures that all operations are performed through the swap cache to prevent lost updates. rw_swap_page_base() is the core function which performs the real work.

The function responsible for deactivating an area is called sys_swapoff(). This function is mainly concerned with updating the swap_info_struct. The major task of paging in each paged-out page is the responsibility of try_to_unuse() which is extremely expensive. For each slot used in the swap_map, the page tables for processes have to be traversed searching for it. In the worst case, all page tables belonging to all mm_structs may have to be traversed.

Read more: Swap Management

A default setup of any browser on any OS has the browser cache located in a specific folder on the filesystem. When any part of the web page is loaded, the respective files are downloaded into the cache folder and rendered by the corresponding part of the browser engine.

Assuming that you are asking about saving the state of the virtual machine, a.k.a. taking a “snapshot”, which for most VMMs means saving the copy of the VM’s RAM at the moment of doing it, plus the copy of the VM’s virtual disk image at the same moment (some VMMs know how to do incremental copies of their VMs, so the whole disk is not duplicated somewhere but used as a new baseline for the saved state of the VM instead, etc.), we can say that the entire browser “state”, both in RAM and on disk, including the whole disk state (which contains the filesystem which contains the folder with the cache) is included into that snapshot.

However, depending on what you are doing with the VM, the VM snapshot can be dependent on the VM disk image (As any incremental backup can be), or can be easily destroyed later, e.g. when you resume execution or take another snapshot while deleting this one, etc., so if you really need to do something with that data, better figure out some way of extracting it.