Hot answers tagged virtual-memory
10
Clean pages are pages that have not been modified since they were mapped (typically, text sections from shared libraries are only read from disk (when necessary), never modified, so they'll be in shared, clean pages).
Dirty pages are pages that are not clean (i.e. have been modified).
Private pages are available only to that process, shared pages are mapped ...
5
Edit: This answer is incorrect. Though still a possible cause for oom-killer to be invoked, it is not the cause in this specific case.
It looks like this is due to memory fragmentation.
From the output you provided, the highest order contiguous memory block you have is a 32kb block in the normal zone. This means that if anything tries to allocate a chunk ...
5
It isn't sticky - you just write to the file to make it drop the caches and then it immediately starts caching again.
Basically when you write to that file you aren't really changing a setting, you are issuing a command to the kernel. The kernel acts on that command (by dropping the caches) then carries on as before.
4
32-bit processes can only allocate up to 1, 2, 3, or about 4GB, depending on which memory split was chosen when the 32-bit kernel was built. 32-bit processes on a 64-bit kernel can allocate about 4GB. 64-bit processes on a 64-bit x86-64 kernel can allocate up to 128TiB.
4
As far as I understand your question it happens usually in such way:
If you allocate memory:
Mark memory as allocated but don't allocate physical memory (hence on access there will be page fault). In Linux it stops at this stage but it is possible that system may allocate physical space immediately - then it performs similar algorithm at the end as on ...
3
You can run swapon -s to see what devices and files are being used for swap. For example, my scientific linux machine says:
[user@sl6.3 ~]$ swapon -s
Filename Type Size Used Priority
/dev/sda3 partition 8388600 833408 -1
So I'm using /dev/sda3 for swap. Also note the priority field that can be ...
3
If you use DISM, make sure you have ample room in your swap.
When you shmat an SHM segment with SHM_SHARE_MMU (which is not the default), you get an ISM segment, which is automatically locked in memory (not pageable). The cost of that mapping, in virtual memory, is just the size of the allocated SHM region. (Since it cannot be paged out, no need to reserve ...
3
swapon have -p switch which sets the priority. I can set up:
swapon -p 32767 /dev/zram0
swapon -p 0 /dev/my-lvm-volume/swap
Or in /etc/fstab:
/dev/zram0 none swap sw,pri=32767 0 0
/dev/my-lvm-volume/swap none swap sw,pri=0 0 0
EDIT: Just for a full solution - such line may be helpful as udev rule:
KERNEL=="zram0", ACTION=="add", ...
3
A 32-bit process has a 32-bit address space, by definition: “32-bit” means that memory addresses in the process are 32 bits wide, and if you have 232 distinct addresses you can address at most 232 bytes (4GB). A 32-bit Linux kernel can only execute 32-bit processes. Depending on the kernel compilation options, each process can only allocate 1GB, 2GB or 3GB ...
3
I admit that the following isn't a great answer, but I believe the 0x8048000 value is enshrined in the ELF Specification. See figures A.4, A.5 and A.6 in that doc. The System V ABI Intel 386 Architecture Supplement also standardizes on 0x8048000. See page 3-22, Figue 3-25. 0x804800 is prescribed as the low text segment address/high stack address. And ...
3
Linux as well as Windows, work pretty much the same here. Every process gets it's own "virtual" address space. This doesn't mean that the memory is actually physically available (obviously most 32bit computers never had enough memory), that's, why it's virtual.
Also the addresses used there don't correspond to the physical addresses. Thereby physical memory ...
2
Virtual addresses are only backed by physical memory and swap when required. A process is welcome to allocate as much memory as it likes, and the system is welcome to not actually give it that memory until it is needed. See the malloc(3) man page, NOTES section for details.
2
3 > drop_caches instructs the kernel to discard all cached data (that are not needed any more).
swapoff will try to pull as much of data, that are currently on swap, as it can back into memory. It may also trigger dropping some cached pages to make room for what is coming into memory from the swap file.
You really only seldom need to do this, the kernel ...
2
Serge answered it. The TLB has a fixed number of slots. If a virtual address can be mapped to a physical address with information in the TLB, you avoid an expensive page table walk. But the TLB cannot cache mappings for all pages.
Therefore, if you use larger pages, that fixed number of virtual to physical mappings covers a greater overall address range, ...
2
“Own virtual address space” actually means the opposite of what you say: it means that the address 11111111 points to a different location in physical memory in every process. If virtual addresses corresponded to the same physical address in different processes, then the processes would share an address space. In fact, some of the address space is shared ...
1
Pages of process memory may be displaced from the RAM to the disk. This is called swapping or paging (the terms are essentially synonymous). The data is moved to the swap space, and loaded back from the swap space when it is needed. Linux supports both partitions (and other block devices) and files as swap space.
If the page in question contains data that's ...
1
This answer is for a IA-32 architecture. I took the information form Intels IA-32 Architectures Software Developer’s Manuals, Page 1751/3044(!):
Table 4-6. Format of a 32-Bit Page-Table Entry that Maps a 4-KByte Page:
0 (P): Present; must be 1 to map a 4-KByte page
1 (R/W): Read/write; if 0, writes may not be allowed to the 4-KByte page referenced by this ...
1
One should not mix up virtual memory and physical volatile memory. The former is CPU architecture specific and will be mapped to volatile and non-volatile memory. The latter, aka RAM, should be independent of CPU architecture from the kernel point of view.
Today's AMD and Intel x86_64 implementation only support 48 bit of addressable virtual memory. Which ...
1
What does the syslog say? Is there any hint that the kernel is killing off processes because of OOM?
How big is the swap? Have you adjusted any kernel in the vm. namespace?
How much is "a bunch"?
What happens in those 30 minutes? What does vmstat -SM 3 look like?
Perhaps most importantly: What applications are you running, (how) are they affected by ...
1
Try Alpine Linux, which will be substantially smaller than Arch. It uses BusyBox/uClibc, but is nonetheless a full-featured distribution. The downside compared to Arch is the community is much smaller, so the wiki is thinner, and so on. But if you know what you're doing, how to find your way around a new distro, and so on, then this is a really nice one. ...
1
You probably want to look at Linux Kernel Crash Dump and proceed mostly as with a userspace crash (debug, recompile, test). Apart from its own documentation you might be interested for example in Linux Crash HOWTO, this short RedHat's guide or this quick guide.
1
Sorry, this should be a comment on Patrick's answer - but I haven't amassed enough rep on unix.stackexchange to be able to comment on his answer.
We are dealing with an unknown application on an unknown embedded platform. Obviously, if we had more information on those two points, we might have a better chance of answering abc's question. It would also be ...
1
The change is reflected immediately. There is no caching along the way. When you read /proc/<pid>/smaps, you actually trigger a traversal of that process's page table. Information about the mappings is accumulated along the way, then displayed, without any caching.
The code behind the /proc/<pid>/smaps file is in fs/proc/task_mmu.c, specifically ...
Only top voted, non community-wiki answers of a minimum length are eligible
