What is the linux command line to check kernel space and User space Memory used [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
I couldn’t able to find the exact details. Is there any command line to find the RAM usage of kernel space and user space memory used.
2 Answers 2
These should give you enough information to estimate the total kernel memory consumption.
You can read more info about kernel and userspace memory here.
Could you elaborate a bit what do you mean by «kernel» in this context and why would you want to separate that from the rest of the system?
to get some idea about memory usage in general. In general «available memory» will be the maximum amount of RAM that can be acquired in near future by processes and if more is requested, the system will slow down. Also note that using all «available memory» also requires sacrifying all of the disk cache which will make future disk access slower.
The memory used for buffers/cache (nowadays a same thing but historically Linux had separate memory areas for those needs) can be examined with sudo slabtop -sc – that displays buffer/cache («slab cache») usage and active use percentage (you can think this as cache hit rate). If the items that take most RAM have high «USE» percentage, your kernel is working fine.
If you really want to speak about «kernel memory usage» you have to decide if kernel modules, page tables, TCP/IP receive buffers, disk cache, etc. are part of the memory you’re interested in. Personally, I really don’t care if some piece is technically kernel process or user mode process — if it’s required for the working system, it needs to stay anyway.
One interpretation for kernel usage:
grep Memory: /var/log/dmesg | \ grep -E -o '9+K (kernel code|data|rwdata|rodata|init)' && awk '' /proc/modules | sort -hr 8198K kernel code 1290K rwdata 3940K rodata 1428K init 1764K i915 1192K xfs 1068K btrfs 572K kvm . What is difference between User space and Kernel space?
Is Kernel space used when Kernel is executing on the behalf of the user program i.e. System Call? Or is it the address space for all the Kernel threads (for example scheduler)? If it is the first one, than does it mean that normal user program cannot have more than 3GB of memory (if the division is 3GB + 1GB)? Also, in that case how can kernel use High Memory, because to what virtual memory address will the pages from high memory be mapped to, as 1GB of kernel space will be logically mapped?
3 Answers 3
Is Kernel space used when Kernel is executing on the behalf of the user program i.e. System Call? Or is it the address space for all the Kernel threads (for example scheduler)?
Before we go any further, we should state this about memory.
Memory gets divided into two distinct areas:
- The user space, which is a set of locations where normal user processes run (i.e everything other than the kernel). The role of the kernel is to manage applications running in this space from messing with each other, and the machine.
- The kernel space, which is the location where the code and data of the kernel is stored, and executes under.
Processes running under the user space have access only to a limited part of memory, whereas the kernel has access to all of the memory. Processes running in user space also don’t have access to the kernel space. User space processes can only access a small part of the kernel via an interface exposed by the kernel — the system calls. If a process performs a system call, a software interrupt is sent to the kernel, which then dispatches the appropriate interrupt handler and continues its work after the handler has finished.
Kernel space code has the property to run in «kernel mode», which (in your typical desktop -x86- computer) is what you call code that executes under ring 0. Typically in x86 architecture, there are 4 rings of protection. Ring 0 (kernel mode), Ring 1 (may be used by virtual machine hypervisors or drivers), Ring 2 (may be used by drivers, I am not so sure about that though). Ring 3 is what typical applications run under. It is the least privileged ring, and applications running on it have access to a subset of the processor’s instructions. Ring 0 (kernel space) is the most privileged ring, and has access to all of the machine’s instructions. For an example of this, a «plain» application (like a browser) can not use x86 assembly instructions lgdt to load the global descriptor table, nor hlt to halt a processor.
If it is the first one, than does it mean that normal user program cannot have more than 3GB of memory (if the division is 3GB + 1GB)? Also, in that case how can kernel use High Memory, because to what virtual memory address will the pages from high memory be mapped to, as 1GB of kernel space will be logically mapped?
For an answer to this, please refer to the excellent answer by wag to What are high memory and low memory on Linux?.
How to access(if possible) kernel space from user space?
How exactly is user memory and kernels memory differentiated inside the Linux kernel(in terms of giving security to kernel space)? What are the different ways I can write in kernel address space from user space? One way I know is through a system call. There are multiple system calls we can use, but at the end they are all system calls. Even in system calls, we send a data to kernel space, where it(driver or respective module) calls functions like copy_from_user() to copy data from user space to kernel space. Here we exactly are not writing into address space. we are just passing a user pointer which contains the data that needs to be copied into the kernel buffers. My question is there any way we can access a physical address that is present in the kernel space and perform operations on it? Second, Apart from system calls are there any other ways I can write into kernel space from an user application? I referred to this link from stackoverflow. But I think my question is not answered there and is from different perspective. Hence I thought of asking a different question. Please share your knowledge. Thanks.
3 Answers 3
What are the different ways I can write in kernel address space from user space?
I’m not sure if there’re other methods, but you can access physical memory using /dev/mem & system call mmap() .
/dev/mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system. Byte addresses in mem are interpreted as physical memory addresses.
You can use the mmap() to map a section of /dev/mem and use in your user program. A brief example code:
#define MAPPED_SIZE //place the size here #define DDR_RAM_PHYS //place the physical address here int _fdmem; int *map = NULL; const char memDevice[] = "/dev/mem"; /* open /dev/mem and error checking */ _fdmem = open( memDevice, O_RDWR | O_SYNC ); if (_fdmem < 0)< printf("Failed to open the /dev/mem !\n"); return 0; >else < printf("open /dev/mem successfully !\n"); >/* mmap() the opened /dev/mem */ map= (int *)(mmap(0,MAPPED_SIZE,PROT_READ|PROT_WRITE,MAP_SHARED,_fdmem,DDR_RAM_PHYS)); /* use 'map' pointer to access the mapped area! */ for (i=0,i <100;i++) printf("content: 0x%x\n",*(map+i)); /* unmap the area & error checking */ if (munmap(map,MAPPED_SIZE)==-1)< perror("Error un-mmapping the file"); >/* close the character device */ close(_fdmem); However, please make sure the area you are mapping is not used, for example by the kernel, or it will make your system crash/hang, and you will be forced to reboot using hardware power button.
Linux kernel space and user space
Thanks in advance for any input, literature/links that can help clarify my questions are okay as well.
2 Answers 2
You’ve got the general idea mostly right, but make this adjustment: there’s only one «kernelspace» for the whole machine, and all processes share it.
When a process is active, it can either be running in «user mode» or «kernel mode».
In user mode, the instructions being executed by the CPU are in the userspace side of the memory map. The program is running its own code, or code from a userspace library. In user mode, a process has limited abilities. There is a flag in the CPU which tells it not to allow the use of privileged instructions, and kernel memory, although it exists in the process’s memory map, is inaccessible. (You wouldn’t want let any program just read and write the kernel’s memory — all security would be gone.)
When a process wants to do something other than move data around in its own (userspace) virtual memory, like open a file for example, it must make a syscall. Each CPU architecture has its own unique quirky method of making syscalls, but they all boil down to this: a magic instruction is executed, the CPU turns on the «privileged mode» flag, and jumps to a special address in kernelspace, the «syscall entry point».
Now the process is running in kernel mode. Instructions being executed are located in kernel memory, and they can read and write any memory they want to. The kernel examines the request that the process just made and decides what to do with it.
In the open example, the kernel receives 2 or 3 parameters corresponding to the arguments of int open(const char *filename, int flags[, int mode]) . The first argument provides an example of when kernelspace needs access to userspace. You said open(«foo», O_RDONLY) so the string «foo» is part of your program in userspace. The syscall mechanism only passed a pointer, not a string, so the kernel must read the string from user memory.
To find the requested file, the kernel may consult with filesystem drivers (to figure out where the file is) and block device drivers (to load the necessary blocks from disk) or network device drivers and protocols (to load the file from a remote source). All of those things are part of the kernel, i.e. in kernelspace, regardless of whether they are built-in or were loaded as modules.
If the request can’t be satisfied immediately, the kernel may put the process to sleep. That means the process will be taken off the CPU until a response is received from the disk or network. Another process may get a chance to run now. Later, when the response comes in, your process starts running again (still in kernel mode). Now that it’s found the file, the open syscall can finish up (check the permissions, create a file descriptor) and return to userspace.
Returning to userspace is a simple matter of putting the CPU back in non-privileged mode and restoring the registers to what they were before the user->kernel transition, with the instruction pointer pointing at the instruction after the magic syscall instruction.
Besides syscalls, there are other things that can cause a transition from user mode to kernel mode, including:
- page faults — if your process accesses a virtual memory address that doesn’t have a physical address assigned to it, the CPU enters kernel mode and jumps to the page fault handler. The kernel then decides whether the virtual address is valid or not, and it either creates a physical page and resumes the process in userspace where it left off, or sends a SIGSEGV.
- interrupts — some hardware (network, disk, serial port, etc.) notifies the CPU that it requires attention. The CPU enters kernel mode and jumps to a handler, the kernel responds to it and then resumes the userspace process that was running before the interrupt.
Loading a module is done with a syscall that asks the kernel to copy the module’s code and data into kernelspace and run its initialization code in kernel mode.
This is pretty long, so I’m stopping. I hope the walk-through focusing on user-kernel transitions has provided enough examples to solidify the idea.