virtual-memory

Consider the following situation: the kernel has exhausted the physical RAM and needs to swap out a page. It picks least recently used page frame and wants to swap its contents out to the disk and allocate that frame to another process. What bothers me is that this page frame was already mapped to, generally speaking, several (identical) pages of several processes. The kernel has to somehow find all of those processes and mark the page as swapped out. How does it carry that out? Thank you. EDIT: Illustrations to the question: Before the swapping processes 1 and 2 had a shared Page 1, which

As the title suggests, I have a problem of obtaining the physical address from a virtual one. Let me explain: Given a variable declaration in process space, how can I derive it's physical address mapped by the OS? I've stumbled upon some sys calls /asm/io.h where the virt_to_phys() function is defined; however it seems this header is outdated and I can't find a work around. However; io.h is available at: /usr/src/linux-headers-2.6.35-28-generic/arch/x86/include/asm/ . My current kernel is 2.6.35-28 , but io.h isn't included in /usr/include/asm/ ? So, to reiterate: I need a way to get the

A co-worker mentioned to me a few months ago that one of our internal Delphi applications seems to be taking up 8 GB of RAM. I told him: That's not possible A 32-bit application only has a 32-bit virtual address space. Even if there was a memory leak, the most memory it could consume is 2 GB. After that allocations would fail (as there would be no empty space in the virtual address space). And in the case of a memory leak, the virtual pages will be swapped out to the pagefile, freeing up physical RAM. But he noted that Windows Resource Monitor indicated that less than 1 GB of RAM was available

I have existing code that takes a list of struct page * and builds a descriptor table to share memory with a device. The upper layer of that code currently expects a buffer allocated with vmalloc or from user space, and uses vmalloc_to_page to obtain the corresponding struct page * . Now the upper layer needs to cope with all kinds of memory, not just memory obtained through vmalloc . This could be a buffer obtained with kmalloc , a pointer inside the stack of a kernel thread, or other cases that I'm not aware of. The only guarantee I have is that the caller of this upper layer must ensure

What is the difference between sequential write and random write in case of :- 1)Disk based systems 2)SSD [Flash Device ] based systems When the application writes something and the information/data needs to be modified on the disk then how do we know whether it is a sequential write or a random write.As till this point a write cannot be distinguished as "sequential" or "random".The write is just buffered and then applied to the disk when we will flush the buffer. Please correct me if I am wrong. When people talk about sequential vs random writes to a file, they're generally drawing a

Ok I have a bit of a noob student question. So I'm familiar with the fact that stacks contain subroutine calls, and heaps contain variable length data structures, and global static variables are assigned to permanant memory locations. But how does it all work on a less theoretical level? Does the compiler just assume it's got an entire memory region to itself from address 0 to address infinity? And then just start assigning stuff? And where does it layout the instructions, stack, and heap? At the top of the memory region, end of memory region? And how does this then work with virtual memory?

Modern x86 CPUs have the ability to support larger page sizes than the legacy 4K (ie 2MB or 4MB), and there are OS facilities ( Linux , Windows ) to access this functionality. The Microsoft link above states large pages "increase the efficiency of the translation buffer, which can increase performance for frequently accessed memory". Which isn't very helpful in predicting whether large pages will improve any given situation. I'm interested in concrete, preferably quantified, examples of where moving some program logic (or a whole application) to use huge pages has resulted in some performance