Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am using custom board with DDR size of 512 MB. I need to reserve a large buffer of physically RAM from the kernel and be able to read /write to that hard-coded physical address.I need to reserve 300-400MB for application.
But i am not able to understand on upto how much memory i can access from the user space directly.
Does the "lowmem" mentioned in layout refer to physical memory of 512 MB. If so , will i am be able to use the complete memory ?
I understand that 32 bit machine allocate 4GB space out of which 1GB for kernel space and 3GB for User space access. But i am not able to figure out the difference of this 4GB and my Ram 512 MB. And how this 512 MB ram fit in kernel space .
We have 512MB DDR 0n our board. The memory address start from 0 to 0x20000000. We have loaded u-boot and booted linux 4.0 .Through application we need to Read /write into any address of physical memory (512MB).(i.e., I need to write into any physical address e.g.,0x100000 of some 1000Bytes and read back the data from the same address).
I used mmap to map physical address and perform read/write.It work fine with small memory size like 20MB but application was not working stable when i map huge memory size like 256MB and above.Got kernel hang or crash frequently.
I am new to linux environment and i am not able to get enough information about virtual memory layout.Below are my Queries,
1) How kernel virtual memory mapped with physical memory.
2) Upto how much physical memory regions i can access from user space and is it safe to access without crashing or affecting kernel memory.
3) Will i be able to access the physical memory with direct address like (0x1000000 0x8000000 )from user space.
4) How much size i can use through malloc and how to know the map size. Do i need to get this information from virtual layout ? but no .heap memory allocated in virtual layout ?
1) virtual memory is dynamically mapped to physical memory (on demand) - as far as I know
2) from user space you are not able to use directly any regions of physical memory, but some memory will be associated to the process and that will be either put into physical ram or swapped out (if possible). This cannot conflict with kernel memory.
3) I don't think so, you need special kernel driver for that - if I know it well
4) malloc will return NULL if no more space can be allocated, The virtually available memory is usually more than RAM+swap.
Can you tell me what lowmem (0xc0000000 - 0xe0000000( 512 MB)) mean in virtual layout ? Is it specifying the physical memory ?
I feel difficult to understand this virtual layout.
Virtual layout seem to be of 4GB for 32bit machine. And the physical memory which i am using is only 512MB.
How kernel uses this physical memory in kernel space for running its process. According to my understanding,kernel should allocate some memory for any process to execute.
So how it allocate the physical memory and how will end user knows it such that application will not touch that memory region or use that region to avoid crash.
I think that you need to use some kind of kernel interface – such as, say, a loadable virtual device. Applications can "open" the device, "seek" to any particular point, then "read" or "write" data. Of course the virtual device restricts itself to the confines of the memory buffer, the physical location of which you already know.
The existing /dev/kmem virtual device is almost identical in concept. (But I would not attempt to use that ...)
User processes do not have direct access to physical memory, and although it would be possible to "map" the physical storage into the virtual-storage image of a particular process, I think that the virtual-device interface would be easier.
Last edited by sundialsvcs; 09-26-2017 at 08:03 AM.
4 GB is the theoretical maximum, but obviously the real hardware will handle only the available memory (but not more that 4GB).
You mean to say that 512 MB can be accessed from kernel space as well as from user space. But will not know exact which physical address it is current accessing (like 0x100000 or 0x8000000). And all physical memory direct address will be as accessed as virtual address in both kernel and user space (like mmap).
And from the Memory map shown below , Memory use 486136K out of 524288K available but its missing 37k out of total memory and why its not exactly using the whole memory. And from Kernel memory map, i understand pkmap to vector uses 1GB kernel space. And remaining 3GB for USER space.And I am able to do malloc upto 300MB in user space but in kernel space kmalloc upto 4MB only. Why i am not able to assign larger memory size in kernel space. And kernel crash,if i use vmalloc of 32MB size,
Actually, no: physical RAM-addresses can't be developed or used by user-land programs.
All user programs run in a virtual-memory environment and cannot escape from it.
As I previously suggested, an obvious and ready solution to this problem is a virtual device, or even a virtual filesystem such as kmem.
There are plenty of already-perfected examples available to you in both cases. Simply 'cabbage' one out of the kernel source-trees, 'whack-a-mole' on it for a little while until it turns into what you need, and use it. Either way, "you do not need to (re-)invent this."
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.